HaloO, 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. closures. Regards, TSa. -- "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
