At 15:36 08.04.2002, Kristian Köhntopp wrote:
>Marcus Börger wrote:
> > -> we have private, what about final, public, protected and
> > abstract (can we remove/hide a method from an object)?
>
>Do we in ZE2? What use it is?
>
>In my book, private is only of very limited use, because there
>always must be a way around it.
So that book is your own meaning. I do more like accepted books on
computer language theory (for OO languages there is only one book:
A Theory on Objects; Martin Abadi, Luca Cardelli, Springer).
>Introducing private (in C++) immediately called for the
>introduction of protected and friend, with protected being a
>mechanism to break privacy along the lines of the inheritance
>hierarchy and friend being a mechanism to break privacy across
>inheritance hierarchies, at compile time.
Yes it does call for it. But please do not use break.
A private method is a method that cannot be used for inheritance.
Thus you cannot implement it another way in a derived class/object.
A protected method is a method that can be used for inheritance but
is not accessible from other classes. A friend is a method/class that
is allowed to handle private/protected members of another class (here
breaking could be used).
>Since PHP does many things at run time which C++ does at compile
>time, there must be a mechanism to break privacy at run time,
>which makes it pretty pointless to have private variables in the
>first place.
Does not because inheritance does not necessary have to be implemented
at compile time. This can be handled using the same words at runtime, too.
The one reason for handling inheritance at compile time is that you can
easier achive type strictness at compile time (but like C++ we don't have
that).
>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)!
>Providing stronger privacy would only force the addition of even
>more syntactic candy (such as a get_private($o, $slot) and
>set_private($o, $slot)). Functions to break privacy are needed
>in order to write Metafunctionality such as a serialization
>agent, or a RPC proxy like the Soaping mixin class I introduced
>in another mail to this list.
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().
> > -> do we allow to reduce visability (replace protected by
> > private as long as we don't have it):
> > class A {
> > public function f()..
> > }
> > class B extends A {
> > protected function f()...
> > }
>
>Same reasoning as above. Make it a warning, do not delve into B&D
>language realms. PHP does things at run time, because we are in
>the rapid prototyping area and flexibility comes before compile
>type checking and static bindings. And anyway, class != type in
>PHP.
Rapid prototyping does not necessary need to have bad design. And
of cause when not using private/protected you can do dirty prototyping
just like without it - BUT you can do really good design. And i thought
we all would like PHP to become *the* solution for web applications.
>Kristian
>
>--
>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
