On 2011-08-20 12:02, Damian Conway wrote:
Carl asked:
* What language components could be provided to put class implementors
on the right path so that their classes end up encapsulated by
default?
Doing nothing should result in the safe behaviour (i.e. full encapsulation).
You ought to have to explicitly request anything else.
One of the *big* selling points of Perl 6 is the prospect of "OO done right".
Leaky encapsulation ain't that.
Sorry if I am hijacking the thread, but how does the .* and .+ fit into
"OO done right" idea?
As I understand it, having a class hierarchy like so:
class A { method m { say "A.m called" } }
class B is A { method m { say "B.m called" } }
class C is A { method m { say "C.m called" } }
class D is B is C { method m { say "D.m called" } }
calling
D.new().+m();
Produces
D.m called
B.m called
C.m called
A.m called
Making it an option (and I suspect sometimes even the responsibility) of
the caller (reading "Calling sets of methods" in S12) to choose how
dispatch should be done, can hardly be said to be encapsulation (a
subset of OO) "done right"?
In other words, any class using .+, .* or $something.WALK( ... ) is - in
the best case - violating the responsibilities of its superclasses. The
.+ and .* operators still look to me as if someone has been mixing up
the chain of responsibility pattern with normal OO method dispatch. On
one hand, there is no reason that .* and .+ should use the inheritance
hierarchy as the dispatch order if we're looking for some generalized
chain of responsibility. On the other hand, explicitly calling each
method all the way up the inheritance hierarchy, ignoring the efforts of
the individual methods to carry out their specialization of their super
classes, just doesn't seem to make any sense.
Regards,
Michael.
