Re: [PHP4BETA] runtime class information

I agree with you that there should be no hardcoded "design" code in classes that you intend to use on more than one site, however i still believe that you can do ot without having to know the member functions, i'll try to give an example (i hope i didn't misunderstand anything). Here's a simple one assuming the object only returns a string that needs formatting. function print_item_formated($object) { $str = $object->print_item(); echo "<font size=\"2\">$str</font><br>"; } For each new site you're doing you dont have to change anything in the class, the only thing you have to care about is the "design parsers" like the print_item_formated() function. In the real world, things are usually more complex but this is the basic idea of how i do "site independent" classes. Another thing i sometimes use is a parse() function in the classes that takes a string and parses it, an example of how it works: <?PHP $obj=new user(); ?> Alot of flashy design ...... .... .. <table> <?PHP $obj->parse("<tr><td><!--Name--></td><td><!--Phone--></td></tr>"); ?> </table> etc the parse function then replaces <!--Name--> with it's appropriate value, you get the idea. I have actually got some of my designers to understand and use it without much help from me :) Well, some of my thought on the topic at least, it would be interesting to hear about how other php users solve these "site independent" coding :) /Johan Isacsson On Wed, 28 Jul 1999, George Hartz wrote: > Johan Isacsson wrote: > > 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. > > I agree, generally. But the case I had in mind, I might have a set of > functions (of which print_item is one) that are functions used for a > particular design on the site, and I might want to isolate those from > the actual logic of the site. For that reason, I don't necessarily want > print_item to be in the object's class, because I may use that object on > a lot of sites. By pulling it out, I can write functions that format > parts of a response specific to a site, and use them generically to > manipulate objects that are used among multiple sites, where I may not > have a defined interface. > > If I'm creating a class specific to a site, then you're right, the way I > presented was a dumb way to do it. > > > 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... > > Well that's the idea. I want to black box it more than I currently can. > Good reusable code should be generic -- I shouldn't be outputting HTML > formatted data from a class, because how it gets formatted may change in > different parts of the site. I should build those formatting routines > into a function for doing a particular formatting task. By > "anonymitizing" (is that even a word?) the objects I pass to it, then I > don't have to write a separate function for each possible object I could > need to display. I could, for example, have functions that return a > string with a text formatted version of an object's contents, and use > that return in the function to display that information arbitrarily. I > might have different member functions that return it in different ways, > and I don't necessarily want to have that hardcoded into the function or > worse yet into the page code itself. (As soon as you put too much code > on the page, it becomes unmaintainable by the designers, and the coders > definately don't want to have to be changing things all the time) > > I guess its just a different way of thinking about the dataflow. I like > having lots of generic objects for doing things, and writing functions > in front of them to handle the formatting of things. To some extent I > code that way anyway, but its not as useful as "$myobject->$myfunc()". I > think you can do that in Perl... I'm a bit fried today, long day. I know > I've seen a language before that allows that... > > > > > 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 :) > > Yeah. Andrey's suggestion to put underscores in front of them was't what > I was talking about. I like the idea of strictly enforcing private > methods and variables. Especially if there's a way to get a list of > member functions, and people can see the undocumented ones. :) > > - george > -- > email:dotorg@bangsplat.org;url:www.bangsplat.org;uin:153182;aim:tgd98 > GCS/GP/GS/GFA d- s+: a- C++++$ UL++++$ P+++$ L+++$ E- W++>$ N+@ !o > K+++ w--- !O M-@ V PS+ PE Y+ PGP t-(+) 5- X++ R-(--) tv+ b+++ DI++ D++ > G+ e* h r y++ >