my Dog $spot;
my Dog @pack;
$spot->@.legs; # INCORRECT (I hope)
$spot@.legs; # INCORRECT?
@spot.legs; # What if you also have @spot declared?
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25¢
http://photos.yahoo.com/ph/print_splash
As a guess, I'd say that it's
$spot.legs;
because as I understood A12 the only way to get at an attribute is
through an accessor method (be it autogenerated or otherwise), which is
quite definitely going to look like that. At least, I hope it is. And it
doesn't matter that it returns a list, because the funny characters
don't mean the same thing they mean in Perl 5 - at least, not all of the
time. They're a bit saner now (IMO).
> How would I call attributes? Specifically, what if I'm calling a list
> attribute from a scalar object?
>
> my Dog $spot;
> my Dog @pack;
> $spot->@.legs; # INCORRECT (I hope)
> $spot@.legs; # INCORRECT?
> @spot.legs; # What if you also have @spot declared?
This question is a little bit like asking how you can detect a hard link...
Attributes themselves are inaccessible from outside the class. All you
can get at is their accessor (if they have one), which is a normal
method called the normal way:
$spot.legs; # Could be for $.legs, @.legs, or %.legs
Which actually brings up an interesting question:
class Silly {
has $.thing=1;
has @.thing=(2, 3);
has %.thing=(4 => 5, 6 => 7);
}
my $silly=new Silly();
say $silly.thing.class; #Int, Array, or Hash?
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
I had assumed that'd be illegal: each of $.thing, @.thing and %.thing
autogenerates a method named thing. I would hope that is illegal, for my
head would hurt otherwise keeping track of what a particular "thing"
means.
We surely don't allow the following in the same class:
has @.thing is Array of Cat;
has @.thing is Array of Dog;
It seems to me that the $.thing/@.thing issue is similar (though the
sigil makes this easier for the compiler):
has $.thing is Scalar;
has @.thing is Array;
--Abhijit
Certainly makes sense to me. The default constructor for Class should be
able to handle this case quite cleanly by throwing an exception the
moment you try to re-define an existing accessor, which would only yield
a warning elsewhere.
Now, just thinking out loud, but that should leave:
class c1 { has @.joe }
class c2 { is c1; has $.joe }
alone because you're not replacing an accessor, you're defining one that
will be hit first by the dispatcher. You are essentially saying that
c2's joe is a scalar, not an array which makes fine sense.
Similarly, if joe were a method in c1, it would still be "replaced" in
the same way. This might lead to some surprises, but I think if folks
understand the relationship here correctly, it will not be an issue.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback