Re: PEAR OO style: associative array parameter vs. unencapsulated cla ss
| From: | Jesus M. Castagnetto | Date: | Fri, 09 May 2003 19:24:23 +0000 |
| Subject: | Re: PEAR OO style: associative array parameter vs. unencapsulated cla ss | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-16076@lists.php.net to get a copy of this message | ||
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