Re: [PHP4BETA] runtime class information
| From: | Johan Isacsson | Date: | Wed, 28 Jul 1999 21:49:08 +0000 |
| Subject: | Re: [PHP4BETA] runtime class information | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-2929@lists.php.net to get a copy of this message | ||
Hi George :)
I was reading about your ideas about getting RTTI info on member functions
of a class and would like to give a comment on why it wouldn't be needed.
First example:
> --------
> class URL {
> var $name;
> var $address;
> function write_link() {
> print "<A HREF=\"$this->name\">$this->address</A>";
> }
> }
>
> function print_item($obj) {
> print "<FONT FACE=\"Arial, Helvetica\" SIZE=\"3\">";
> if method_exists($obj, "write_link") {
> $obj->write_link();
> }
> print "</FONT>";
> }
>
My suggestion:
Move the print_item function into the object instead. Your class should
know what function to call in order to get the desired output. For all
your classes, make a print_item function.
Second example:
> ----------
> function print_item($object, $outputmethod) {
> print "<FONT FACE=\"Arial, Helvetica\" SIZE=\"3\">";
> if (method_exists($obj, $outputmethod)) {
> $object->$outputmethod;
> }
> print "</A>";
> }
>
> Then I can call print_item for any object, regardless of how its coded,
> if I have a method that can produce the output. Or I might have class
> that holds more than a simple URL, and I might want member functions
> that print different things, and it'd be cool to be able to call them
> like in the example above.
>
Again, make it the other way around, let the objects handle their own
printing, thats one of the great things about OO, you should treat it as a
"black box" that has a simple interface and takes care of all it's
variables and functions without you having to know about them.
It's still general as long as you have a print_item function in all yout
classes...
> On a side note, has there been any talk of differentiating between
> public and private methods? I have an extensive class library that gets
> used on a bunch of client sites that consists of about 50 classes, each
> has probably 10 member functions. Most member functions I don't want the
> client code to be able to use, but I've found myself from time to time
> cutting corners and using them even thought *I* know I shouldn't.
Yeah, i agree with you there, it would be really nice to have
public/private methods and variables :)
/Johan Isacsson