Re: classes, instances & objects in ZE2

At 11:34 09.04.2002, Kristian Koehntopp wrote:

On Tue, Apr 09, 2002 at 11:11:58AM +0200, Marcus B?rger wrote: Keywords are better then implicit definitions. Agreed. I would like to have private, protected and public which can be easily done by adding one single flag to the members of an object. So how would you set or reset these flags at run-time?

I DO NOT WANT TO! If design is correct i do not have to!

With friends implementation may be much harder because each class or even object has to have a friends list. Why would friend be necessary in the first place, when you simple could class A { private $slot; } class B { function do_with_an_A(&$someA) {

    @$someA->slot = 10; // I know it is private and I intend to break it.

} } "friend" is just a compile-time declaration of a list of classes for which you intend to break privacy, and if you can to it anyway at run-time, you do not need such a declaration.

You simply ignore every information available to code execution here. Then i do not have to say anything about private and so on. There is a difference of programming in small and in teams. If working alone i would not need to say anything about visibility. But when working in teams i would like to make the defined and agreed or published method and member subset public. So only the programmer that is responsible for a class must know about the private members. The protected members are for the group that works on a class hierarchy. I think this is a key discussion for PHP. Do we want PHP to be acceptable for big projects or not?

protected and friend are commonly compile-time mechanisms, so they are not sufficient for us, unless you refer to an uncommon case where protected() and friend() are being used as functions on existing objects or classes in order to modifiy accessibility attributes after object instantiation.

Why are they not sufficient? Because, again, they require a complete and finished declaration of privacy breakage at compile time. That is lacking dynamism, and for some more advanced applications such breakage at run-time would be extremely handy. There is nothing that forbids us to save information generated for the compiler tree into our classes/objects and using them at run time. "using" would not be enough here, "modifying" or "ignoring" would be called for.

Again i want to use them not modifying or ignoring. And if you do not use private and such your classes are all friends. Or in other words you can simply leave such modelling aspects aside.

Kristian -- Kristian Köhntopp, NetUSE AG, Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php