On Tue, Jan 07, 2003 at 10:04:09AM -0800, Michael Lazzaro wrote:
> I think this may be another case of "it depends on what the word 
> 'object' means", e.g. we're talking past each other.  I hope.
> 
> Let's operate from the assumption -- or somebody please CORRECT ME IF 
> I'M WRONG -- that the following syntax is valid:
> 
>     my int @a;                                # 1
>     my @a returns int;                        # 2
>     my @a is Array of int;                    # 3
>     my @a is Array returns int;               # 4
>     my int @a is Array;                       # 5
> 
> Those lines are all absolutely synonymous, and all declare an array of 
> integers, right?  

Doesn't jive with me. I'm not sure what "returns int" means and numbers
5 and 1 don't read well. The first one says (to me) that this thing
called @a is an int. It doesn't say anything about the contents of @a.
#5 has the same problem.

If this is one of those set-in-molded-clay kinds of things, someone
please point me at the relevant discussion.

> Likewise, Arrays have methods:
> 
>     my int @a = (1..100);
>     print @a.length;               # prints "100"
>     my @b = @a.grep { $_ > 50 };   # gets 51..100
> 
> ... which is also known, based on previous Apocalypsii.
> 
> If we accept those as valid syntax -- and I *think* they have been -- 
> then P6 Arrays are objects.  Or, at minimum, they cannot be _discerned_ 
> from objects, regardless of implementation.
> 
> Now, what that looks like in Parrot I have no idea.  But I'm assuming 
> those all will work in P6, because (again, correct me if I'm wrong) 
> Larry has stated they will.
> 
> Is there ANY QUESTION about ANY of that? 

This all fits with my mental model (except for the declaration syntax).

> The remaining big question, then, is whether you can truly subclass 
> Array to achieve C<tie>-like behavior:
> 
>     class MyArray is Array { ... };
> 
>     my @a is MyArray;
> 
> It would seem remarkable if you *couldn't*, right?  

Indeed.

[ snip ]
> 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)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Reply via email to