On Wed, Mar 23, 2005 at 06:58:51PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: > my @array of Int;
: >
: >is really short for
: >
: > my @array is Array of Int;
:
: How does 'is' relate to 'does'? I mean is the above @array
: ready for operation?
Yes, I think "is" typically implies construction of the variable's
main object. Note that this is the trait "is" rather than the ISA
"is". (The way it currently stands, ISA "is" is just the usual side
effect of applying a trait to a class.)
: Whilst
:
: my @array does Array of Int;
:
: still needs a compatible object to be put into @array?
I would think that'd be short for
my @array is Array does Array of Int;
which is kind of redundant, so no, I don't think it stubs out @array.
: Like so:
:
: class Blubber does Array of Int {...}
:
: @array = Blubber.new; # or with := ?
If there were a syntax for stubbing @array, it'd have to use := I think
to initialize.
: BTW, does
:
: my Int $value;
:
: expand to
:
: my $value is Ref of Int;
:
: or the often mentioned
:
: my $value is Scalar of Int;
:
: and what is the difference between the two, if any?
The latter, I expect. The former kind of implies to me that you
could only assign a reference to it, not a normal integer value.
Though there's certainly some overlap there, and they effectively
come out to the same thing in most cases, so it's possible they
might be forced to mean the same thing. On the other hand, maybe
my @value is Ref of Array of Int;
is the syntax you're looking for to stub out an array type without
allocating an array.
: What exactly does the 'is shape' syntax expand to?
: I guess it is some parser gymnastics that somehow
: puts more aguments into the Array class closure.
Traits are just names for code that is run at compile time to tweak
whatever they are applied to. A trait can do anything it pleases
with the object you apply it to. In the case of "shape" it might
even swap in a different set of methods entirely. (Change vtable
in Parrot terms.)
: Which brings me to the question: how does this parameter
: list look like?.
:
: class Array[ ::ContentType, List of List $shape ] {...}
I would not assume it has to come in as a parameter to the type name.
The type correspondences of arrays will have to be negotiated by the
types involved somehow, and that may or may not be done by comparing
the "long names" of types that include the parameters. (If we don't
do it that way, then there has to be some other interface for it,
of course.) I'd like to leave a little wiggle room for structural
correspondence of types, not just named correspondence. This being
Perl, we need to provide a little room to dwim in, even if the user
doesn't take us up on it.
If this sounds inadequately handwavy, please allow me to wave my
hands some more till it's adequately handwavy. :-)
: And yet another one: when is the resulting expansion of
: such a class template or whatever it is performed?
At compile time, by the trait(s) in question, and perhaps by an implicit
instantiate call of some sort after the last explicit trait is parsed.
: Or does the implementor of the class have to revert to blessing in
: the constructor?
Somebody's gotta construct the variable at some point, whether it's
with .bless or some other mechanism.
: Wouldn't this prevent static type checking
: unless the compiler would call the constructor in some
: hypotheticality mode to produce type information.
There very little that is "static" about compiling Perl, except insofar
as things like traits are guaranteed to run code at compile time.
So there's no need to run things hypothetically. You run it really,
and then look to see if you're happy with what you ended up with.
I suspect "static" type checking in this Brave New World is less
about evaluating passive data structures for consistency and more
about asking various objects if they're happy with each other so far.
We just have to define the right interfaces for asking the right
questions at the right time. Piece of cake. I'll let you work on
that part. :-)
Larry
