Re: Package Proposal: Image_JPEG

<sdelmont@zonageek.com> wrote : > I have considered that alternative, and I don't believe it's a good idea > right now. > > There is a lot of "overhead" in the way I read the files, just because I > need to write the data back. And because I need to parse more data than > just the IPTC block. > > And my data structures are somehow different than Image_IPTC / > exif_read_data()... Because of the read/write requirements, and because > the iptcdecode() methods were hard to use and unsuported, and because > exif_read_data was really a mess until recent versions. > > Also, incorporating the "native" methods to my class (or the opossite) > would mean adding more clutter to the interface... When you create an > object... is it for read-only or read/write? Do you want to use the > native methods or the the php code? What version of the native methods > are available? > > I'm not saying that it is impossible. > > I'm not saying that if it is done, it would not be a lot "cleaner" than > what we have now. > > What I'm saying is that it would add complexity. It would make all > modules harder to maintain. And it would take a lot of work for not much > gain compared to what we have right now. I vote for simplicity. Personally, I don't care if more than one class do the same job as another one or a subset of it as long as it does it well. Two classes can have a very different internal logic and interface. Your class seems easy to use and it looks like you have some experience with it. Image_JPEG is clear for me, it's a jpeg image manipulation class. So +1 for the name and the class. Please add PHPDoc comments and change your elseif to: if () { } elseif () { } Instead of : if () { } elseif () { } Bertrand Mansion Mamasam