Re: PEAR OO style: associative array parameter vs. une ncapsulated cla ss
| From: | Alan Knowles | Date: | Sat, 10 May 2003 05:59:19 +0000 |
| Subject: | Re: PEAR OO style: associative array parameter vs. une ncapsulated cla ss | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-16092@lists.php.net to get a copy of this message | ||
This is the code that DataObjects now uses for setters/getters - in principle enabling error strings to be returned from setters, and user friendly values from get/ as apposed to DB native using $object->xxxx .
class example {
var $abc;
var $cdf;
function __call($method,$params,&$return) {
// ignore constructors : - mm
if ($method == get_class($this)) {
return true;
}
// ignore everything that's not get or set
$type = strtolower(substr($method,0,3));
$class = get_class($this);
if (($type != 'set') && ($type != 'get')) {
return false;
}
// ignore privates
$element = substr($method,3);
if ($element{0} == '_') {
return false;
}
// it appear to cause problems for some reason...
$array = array_keys(get_class_vars($class));
if (!in_array($element,$array)) {
return false; }
if ($type == 'get') {
$return = $this->$element;
return true;
}
$this->$element = $params[0];
return $return = true;
}
}
overload('example');
$t = new example;
$t->setAbc(12);
echo $t->getAbc();
now as soon as you define a real method getAbc() or setAbc() the above default method is not called.
you can still use direct access which is faster, (in DataObjects some of the more automated methods, like setFrom and toArray will call the setters/getters.)
This is especially usefull for things like dates which you rarely want to show the end user the raw database format..
Regards
Alan
Jesus M. Castagnetto wrote:
(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:-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.comJesus, 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:===== --- 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.comHello, 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() {===== --- 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$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