At 10:47 09.04.2002, Kristian Koehntopp wrote:
>On Mon, Apr 08, 2002 at 05:18:07PM +0200, Marcus B?rger wrote:
> > >In my book, private is only of very limited use, because there
> > >always must be a way around it.
> >
I skipped the first part because i think we are now talking about the
same thing here. I find it very hard when discussing such things and
all people use phrases as they like instead of their accepted meaning.
>I get this as meaning: It is a bad idea to encode attributes of
>variables such as scope, visibility and accessability into the
>name of a variable and it would be better to use keywords for
>this. I concur with that.
>
>Traditionally, PEAR used the "_" prefix to mark nonpublic slots
>in classes due to the lack of better mechanisms. So "private" as
>a keyword is probably better suited than my suggestion of using
>"_" as a prefix to a variable name.
Keywords are better then implicit definitions.
Remember the discussion about __get_x() going on now, too.
> > >I'd rather go for a warning that is being triggered whenever I
> > >access $a->_slot, but not when I access $this->_slot ("Access to
> > >private object member"). I could suppress this warning by writing
> > >$a->_slot as @$a->_slot instead.
> >
> > We could do this by issuing an error instead of a warning (and we should)!
>
>So how would we break privacy at run-time, then? The @-prefix
>for statemens only supresses warning messages, but does not
>allow continuation after error. If accessing a private slot in
>an object the regular way throws an error, we need a complete
>alternative syntax to be able to do this at run-time. I frown on
>this, because it adds a lot of complexity to the language.
>
>Issuing a warning instead allows us to use the "@" statement
>prefix to access private slots in a class where we explicitly
>intend to do this, and still get notification for all accidental
>accesses to private slots.
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.
With friends implementation may be much harder because each class
or even object has to have a friends list. For classes or even objects this
could be a simple list. But when allowing freinds for functions or methods
its getting real hard i suppose.
> > As already mentioned above we could use friend or referring to the
> > other OO discussion going on we could use aggregation to achieve
> > this. So there is no need for get/Set_private().
>
>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? And why not having friend and protected
working a bit different than in C++. Just because many people use C++?
That would be a bad reason!
There is nothing that forbids us to save information generated for the compiler
tree into our classes/objects and using them at run time.
By the way: In C++ you have dynamic_cast<> operator which works at run
time using rtti , too.
>Kristian
marcus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
