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
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
