Ter, 2008-04-29 às 11:54 +0200, TSa escreveu:
> > If we are to define an operator to declare that some arbitrary object
> > conforms to some API, I would think the following as saner...
> > sub foo(Point $p) {...};
> > FoxPoint $fp = ...;
> > $fp realises Point;
> > foo($fp);
> Here the spec is quite clear that 'realises' is spelled 'does'.
> This is the infix operator that composes a role into an object's
> class at runtime.Not really... 'does' is a composition operation, 'realises' would be just a type annotation that doesn't change the actual composition. > > This way, the dispatching mechanism is still the same (and still typed), > > but the object now also answers true to .^does(Point). > But note that > FoxPoint $fp = ...; > $y = $fp; > $y === $fp; # obviously true > $fp does Point; > $y === $fp; # false because of different HOW? Wrong. $fp is still the same object and $y would also answer true to .^does(Point). it's an in-place change, not a copy. you would need to do $y = $fp.clone(); to keep the non-typed version. > Unfortunately S03 doesn't say if === checks for the same WHAT or the > same HOW as precondition to checking the WHICH. It doesn't. By definition. === only checks WHICH. > Generally WHAT is also quite underspecced. WHAT is implementation specific, it's underspecced for that reason. > > Which means that the typed code remains typed and the feature is > > implemented as a trait that can be used to any object, thus leaving the > > fragile type inference to the code calling the method and not to the > > method that wants a stronger typing... > I don't understand what you want to say here. I mean, the code that is calling the method would be the one doing the untyped->typed mapping, not the calling sub signature (which would make the dispatch much slower). daniel
