I agree with Kristian here; it is quite common to need to break
the protected/privacy rules when the class hierarchy is badly designed.
I'm referring to Delphi here where code like this is required because
someone didn't make something public when they should have.
It's a double issue: 1) is that the class is badly designed, 2) is
that this "hack" is even possible.

/* psuedo code */
class ImageList {
   protected HImageList; /* should be public, or have a getter */
};

// In some other code that uses winapi and needs the handle
class ImageListHack {
   public HImageList;
};

handle = ((ImageListHack)imlist)->HImageList;

On 09/04/02, "Marcus Börger" <[EMAIL PROTECTED]> wrote:
> At 15:36 08.04.2002, Kristian Köhntopp 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.
> 
> 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).




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to