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.

Reply via email to