Re^4: Thoughts on new 'class' OO in upcoming perl

[cavac]

Child classes have no access to parent attributes unless there are (public) accessor methods for them.

That does not make any sense to the way i do OO. Often enough, i write a base class which does the basics, like for instance, handling a websocket. Then i subclass this and override the empty methods in the base class i need to handle this specific websocket connection. I would still need access to all the stuff in the base class. Yes, technically, i could write accessors, but the would just bloat the code and make it slower. It wouldn't provide any benefits that i can see.

In fact, it might be contraproductive to provide public methods to access the internals in some cases. I might want to give the child classes the ability to fiddle with internal settings of the websocket, but not provide the object creator (? i mean the object that called new()) the same kind of access.

[haj]

Indeed, I guess that this design decision could be a major obstacle for adoption of the new core OO. It is a consequence of the intended encapsulation of classes: Fields without accessors are private to the class, and different classes (and roles) in a class hierarchy can use the same field name without conflicts.

There have been lengthy discussions about allowing subclasses direct access with an explicit "opt-in" mechanism (similar to protected in Java), and I would love to see that. However, this will not happen in the first version of core OO.

[Jenda]

This is what "protected" is for in other OO systems. The stuff you want hidden even from the subclasses is marked private, the stuff you want them to have access to is protected, the stuff you only want to access within the library is internal and only the stuff that's supposed to be ... erm ... public is public.

private and public on their own is NOT enough.