On Wednesday, January 8, 2003, at 02:17  AM, Damian Conway wrote:
Jonathan Scott Duff wrote:
On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
>
Which, in turn, implies that the lines:

my Foo $a; # (1)
my $a is Foo; # (2)
my Foo $a is Foo; # (3)

are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not.
Um ... ick. I'd hope that "autoinstantiation" wouldn't happen without
some clear syntactical clue. (I don't think "is" that clue. To me
all three of those look like they should just earmark $a to contain a
Foo and this Foo-thing can/will be instantiated later)
I doubt it. The C<is Foo> tells Perl that this variable is *implemented*
by a (hidden) Foo object. The variable better be able to get in touch with
that "inner Foo" at the point the variable is first used in any way. So
it probably needs to be autocreated at the point of declaration (or, at
least, trampolined into existance before the variable is first used).
Yes, I should have used something more clear than "Foo", and it would have been more obvious what I was getting at:

my MyScalar $a; # (1)
my $a is MyScalar; # (2)
my MyScalar $a is MyScalar; # (3)

(1) creates a scalar variable that may store a MyScalar value.
(2) creates an untyped variable in which the scalar variable $a is _implemented_ by an instance of class MyScalar.
(3) creates a variable that stores a MyScalar AND is implemented by an instance of class MyScalar.

Note that (3) is just plain sadistic. My point was simply that scalars, like arrays and hashes, also should use the 'is' syntax to declare an implementor class, and that the implementor class is, by necessity, always autoinstanciated.

E.G. this is what our new C<tie> syntax is gonna look like, fates willing.

MikeL



Reply via email to