RE: [PEAR-DEV] OO wrappers (was : Need 1 more vote for Image_IPTC class)

Well, I can patch the IPTC extension source with constants instead of using defines. The wrapper class does something the iptcembed() function alone can't do - create an IPTC block that can be embedded. If I did supply such a patch, would I have define the constants as: IPTC_KEYWORDS IPTC_OBJECT_NAME . . etc. I will also be changing the member properties to use underscores since they are all private. My reasoning for wrapping the iptcembed() and iptcparse() functions is to abstract the low-level interface they provide with a high level interface that properly allows anyone implementing the class to manipulate and read the IPTC block of JPEG and TIFF images. My understanding of the PEAR group is to create a set of well-defined, documented, and easy-to-use classes that can be used for rapid-deployment of software. The need for multiple constants in this class stems from a need to free the implementor from knowing each of the numeric codes that correspond to the official offset into the IPTC block itself. If I only provided a few of the "well-known" elements, the class would not be complete. This is a toss up here - speed vs. robustness. However, as aforementioned, I'd be happy to patch the C source code with constants instead if that is a better solution (speed wise, anyway). If you have questions, comments, or suggestions about the aforementioned message, you can respond by replying to this message or contacting us at (309)-743-0800. Thank you. Regards, Patrick O'Lone Internet Software Engineer TownNews.com (309)-743-0809 polone@townnews.com > -----Original Message----- > From: Lukas Smith [mailto:smith@backendmedia.com] > Sent: Tuesday, April 08, 2003 9:46 AM > To: 'Xavier Noguer'; 'Ant-1'; pear-dev@lists.php.net > Subject: RE: [PEAR-DEV] OO wrappers (was : Need 1 more vote > for Image_IPTC class) > > > > From: Xavier Noguer [mailto:xnoguer@rezebra.com] > > Sent: Tuesday, April 08, 2003 4:38 PM > > > El Mar 08 Abr 2003 10:09, Lukas Smith escribió: > > > > From: Xavier Noguer [mailto:xnoguer@rezebra.com] > > > > Sent: Tuesday, April 08, 2003 4:02 PM > > ... > > > > In my opinion PEAR packages shouldn't use wrappers. It's one > thing to > > > > create > > > > an OO wrapper so that people have more choices for > using a certain > > > > functionality, and another one to force anyone using a > different > > > > functionality to have to deal with the overhead of that wrapper. > > > > > > So you prefer a CS mix? > > > Especially if these classes are extended we get huge > problems with > > > naming conventions. Actually as the core of PHP becomes more and > more OO > > > friendly we will find ourselves often in this situation (see the > > > Exception class Sterling is writing). Then we might as > well through > the > > > PEAR CS out the window now. > > > > I'm not following you. I don't see how: > > Maybe I am not following that Rasmus and you are saying either :-) > > > $foo = new Foo(); > > $foo->bared(); > > > > is better than: > > > > $foo = foo_create(); > > foo_bared($foo); > > > > I'm talking about plain wrappers, wrappers that don't add any > > functionality to the one provided by the original php > extension they > > are wrapping. > > I did not look at the details of the class from which this > thread originated, but if I understood the issue correctly > this class does add functionality beyond what the PHP > implementation does. > > Of course there is no reason to wrap PHP native functionality > just to make everything PEAR CS compatible. PEAR aims to > extend PHP and not to wrap all of PHP functionality into a > different API. > > But we do run into problems if we extend classes that follow > a different CS. > > Regards, > Lukas > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >