On May 23, 2009 04:19:53 pm John M. Dlugosz wrote: > > @y just means "the argument must do the Positional role", so it's a > > looser constraint than "is Array". Equivalent is more like: > > > > sub f2(Positional $x) { } > > > > Thanks, > > > > Jonathan > > I'm finding a difference in how a Positional is "bound to" a plain item > variable. > If the paramter-argument bond is shown as: > > my $x := @A; > > > how can the Item variable "really" bond directly to the Positional > object? It doesn't have STORE and FETCH methods. The item variable > forwards methods to the contained item, and a directly-bonded Array does > not. > If you think of parameters as being slots and the type information as being conditions on the objects being put into the slot, then an object is allowed to be put into a slot only if it meets those conditions. Once the subroutine starts to run, then it uses the passed in object directly (e.g. the @A), but with its own name (e.g. $x): no additional containers.
> I think I'm assuming more is (can be) happening at compile time. > The delegation would have to be handled at run-time, rather than as > something the compiler knows about? > Defining the constraints happens at compile time, but everything else happens at run time (including checking the constraints). For example (from rakudo): > sub f1(@y) {say @y.WHAT}; my $x = 1, 2, 3; f1($x); $x = 5; f1($x) Array() Parameter type check failed; expected something matching Positional() but got something of type Int() for @y in call to f1 in sub f1 (<unknown>:1) called from Main (<unknown>:1) > Regards, Henry Regards, Henry > Thanks, > --John -- Henry Baragar Instantiated Software 416-907-8454 x42