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