RE: [PEAR-DEV] PEAR OO style: associative array parameter vs. une ncapsulated cla ss

(cc'ing pear-dev too) I was more pointing to the use of the __call() method to implement accessors, as the method name is passed to you if can decide what to set/get. As for __get()/__set(), they are there as convinience methods (if I understand correctly), so if a particular var does not really exist but is generated from (for example) a database query and some math, it will be done that transparently to the user. Usually there is no enforcement of setter/getter methods in PEAR, to keep things flexible and along the lines of KISS which is what PHP is good for. In that respect, when someone uses "$obj->foo = 'new value';", in reality, the __set() function might be storing that data in a database or shared memory, etc, or calling a method in an object contained in it. You will not use that flexibility all the time, but it is good that is there when you need it. If (when) I get some time, I might add some more to the overload() page in the manual, with an example like the stuff above which might clarify some of the concerns/doubts/questions. HTH --- Bill McCoy <Bill.McCoy@PictureIQ.com> wrote: > Jesus, > > Thank you for your answer. It's nice to see that the overload extension is > now standard in PHP 4.3. I hadn't realized that. > > However your suggestion does confuse me a bit: the __get()/__set() parts of > the overload extension implies to me that Java-style "getter" methods to > preserve encapsulation are now stylistically and semantically unnecessary in > PHP: a client can now directly reference a public class instance variable, > and be assured that whatever semantics are required will be invisibly > provided. But in my case there are no such semantics, since my object is > "thin". In this case why bother to overload __get()/__set()? I have a > similar question with the manual entry on overload - > http://www.php.net/manual/en/ref.overload.php - in the provided > example's OO > class it looks like the behavior if the __get/__set functions were omitted > would be precisely the same, i.e. they just mirror the default behaviors. I > know it was stated as a simplistic example but I kind of expected it to > illustrate a use case for overloading. But maybe I'm missing something... > > --Bill > > -----Original Message----- > From: Jesus M. Castagnetto [mailto:jcastagnetto@yahoo.com] > Sent: Friday, May 09, 2003 12:24 PM > To: Bill McCoy; 'pear-dev@lists.php.net' > Subject: Re: [PEAR-DEV] PEAR OO style: associative array parameter vs. > unencapsulated cla ss > > > Hi Bill, > > Using the overload extension in PHP (compile by default in the recent PHP > releases), you can easily define accessor functions using either a __call() > function or similar. > > As for using an object to pass just data. That depends on your taste. > Usually there is an overhead when passing an object vs an array, not that > bad in most cases, but if you ought to pass a lot of data, perhaps it will > be better to pass a reference to a configuration object of sorts. > > Check the examples of overload in the PHP source tree (php4 in cvs.php.net) > > --- Bill McCoy <Bill.McCoy@PictureIQ.com> wrote: > > Hello, > > > > I'm a newbie to PEAR and not so experienced in PHP either. I ask this > > question here because a) I am developing a package which may > > conceivably be suitable for PEAR someday and b) I respect the careful > > attention to architecture and style by PEAR developers. > > > > The question: is it reasonable PHP programming style to pass a set of > > parameters or options to a method as a class instance rather than an > > associative array instance, even when this means the class is not > > encapsulated (i.e. doesn't use "getter" methods)? > > > > I ask because I observe that passing options arrays as parameters > > seems to be a common PHP idiom. This works around the lack of true > > overloading as well as the need to pass parameters 1..(N-1) in case > > one wishes to provide optional parameter N. Some PEAR packages such as > > Cache_Lite use this idiom. > > > > I thought to do something similar but I have a need for default values > > other than "null", so a routine to set these default parameter values > > would be helpful. But I realized that in PHP associative arrays are > > almost equivalent to objects, and thus I could define a class that in > > effect models an associative array but also has a constructor. A side > > benefit of this is that the supported parameters and default values > > are precisely communicated in the class definition, rather than just > > being a comment. For example: > > > > class RetrievalOptions > > { > > // usage: create instance, then customize class > > // variables that require non-default values > > > > var $creation_timestamp; > > var $author; > > ... > > function RetrievalOptions() > > { > > $creation_timestamp = time(); > > $author = ""; > > ... > > } > > } > > > > > > Although such an class doesn't look much like a typical Java or C++ > > class, these languages don't have PHP's convenient and flexible > > near-equivalence of associative arrays and objects. Of course I could > > define "get" and "set" methods but for a construct that's merely > > a > > package for passing options or parameters that seems a bit > > heavyweight. Also, of course I could simply use "null" as a trigger to > > use the special default values but then these default values would be > > buried in various places in my code and testing array_key_exists deep > > in loops etc. may be less convenient. Someone customizing an instance > > of the above could even choose not to treat it as an object, but > > rather to use the $myParams["author"] array syntax. And, similarly > > such an object could be extended by subclassing (extends...) or simply > > by defining new key-value pairs. I was a bit suprised but pleased to > > find that all the above work fine with PHP objects. Of course another > > idiom is to have generic "getProp/setProp" rather than > > per-instance-variable getter methods, but a totally generic "getProp" > > seems a bit gratuitious in this situation - since basically the object > > itself is already an associative array and directly supports the > > assoc. array accessor syntax. > > > > So, while such a "naked instance variable class" would in most cases > > be considered appalling C++/Java style, it seems like it might be OK > > PHP style, and maybe a good use of PHP "pseudo-objects" (again, in > > "lightweight" situations like configuration parameter passing when > > encapsulation through individual "getter" methods would be overkill). > > Do people have opinions or precedents on this? Thanks in advance. > > > > > > Bill McCoy > > bill.mccoy@pictureiq.com > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > ===== > --- Jesus M. Castagnetto (jcastagnetto@yahoo.com) > > Research: > http://metallo.scripps.edu/ > Personal: http://www.castagnetto.org/ > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com ===== --- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Personal: http://www.castagnetto.org/ __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com