Daniel Ruoso wrote:
I don't really see what this "is :strict" means in the runtime
environment. Perl 6 takes OO so deeply that even the type checking is
implemented as a cal to the object. There isn't really a way of asking
"are you trully really a Dog?", there's only "do you 'Dog'?".
Sorry, where is this specced? If anything than Perl 6 is operator
oriented. That means it is *not* the object that decides for itself
but the does operator. The split between the method form and the infix
form is just there to distinguish the question form "does it?" from
the command form "make that it does!". Also the "call to the object"
has the wrong connotations. You should think about it as a "call on the
object" or "call with the object" because the important concept is the
call not the object.
Classical OO has serious design flaws. E.g. a ball cannot kick itself.
That is the ball in a game is a proper object that has nothing to
decide about its kicking. It is the players who kick the ball. You
can think of them as objects if you like, but in grammatical terms
the players are subjects! Or think of adding numbers. It's hardly
the case that a number object either adds itself to another or the
other to itself or whatever. It is of course the addition operation
that deals with the numbers.
Also the idea of methods being subordinate to objects is fundamentally
flawed, as well. Getting at methods through an object is a very good
implementation strategy for single dispatch that's all. For MMD that
simply breaks down and the method is up front.
Now the other important feature of classical OO is privileged access
to internal or hidden data---encapsulation for short. But there are
different implementation strategies to achieve this goal, e.g.
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan