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. > > So that book is your own meaning.
No, an english ideom. http://www.m-w.com/cgi-bin/dictionary?va=book "- in one's book : in one's own opinion" I wrote: > >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. meaning: A private variable is encapsulated, not accessible from outside the class. This is often to strong a protection and therefore the introduction of private variables usually triggers the introduction of mechanisms to subvert this privacy, with protected and friend being such mechanisms, and with proctected working along the inheritance hierarchy and friend across it, and with both mechanisms working only at compile time. You rephrase this, acknowledging my definitions: > 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). I wrote: > >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. meaning: mechanisms that subvert privacy at compile time are not sufficient or adequate for a language which does many things at run-time. I believe we agree on this, but cannot find direct evidence for that in your comment - do we agree on this particular point? You comment: > Does not because inheritance does not necessary have to be implemented > at compile time. For example, using aggregate. > This can be handled using the same words at runtime, too. 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. > >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. > 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. 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
