On Thu, 2003-01-30 at 13:13, Garrett Goebel wrote:
> Hmm... $0[$!]
>
> However isn't that something the collection object should have to deal with?
> It seems like such nice thing to unify collection syntax.
Actually, that's a great example, and there are certainly others.
According to Larry, that object will have both a Buddha nature and a...
er that is, a string and numeric representation. Other objects will be
able to behave in this context-sensitive manner as well.
Let me switch that one around for you:
class MyContainer {
method index($object) { ... } # index by any scalar object
method index(int $ind) { ... } # index by a number
}
my MyContainer $x;
$x.index($!);
What does *that* do? Ultimately, C<$x[$!]> is no different, and if we
have a resolution for one, we have a resolution for the other.
What's more, even if we do decide not to unify arrays and hashes (as I'm
assuming we will), I'm pretty sure we still need to answer this
question.
Options include:
* Run-time error
* Default to most generic type with warning
* Default to most generic type without warning
* Default to most specific type (huh?) with warning
* Default to most specific type without warning
I'm not sure what I meant by "most specific", but it sounded like that
should be one of the options. Can anyone else read my mind better than I
can? :)
> > And because some built-in redundancy is useful for error checking,
> > especially on complex nested data structures.
>
> I'm no one to argue with that...
True, true. And, joy of joys, that error checking is available. We can
allow a warning mode where variables with undeclared types cause
warnings like so:
module strict 'types';
my @a; # Warning/error due to lack of type
my hash @a; # No problem
I would be very distressed if we did not allow for this. We already have
warning modes in Perl 5 for auto-vivification of undefined references,
don't we? So, that case is taken care of.
Is there any other ambiguity that we should be concerned about?
About the dead-horse thing... Others have asked why we should pursue
this. My feeling is that we're grasping in the dark at some core beliefs
that we don't really have good reasons for. I'm hoping that as we poke
deeper at this, we'll find more and more of those core beliefs either
have good reasons or can be given a different form without shaking our
faith (as with the above polymorphism example). If I was willing to
"just take it on faith", I'd be programming in Java. Perl is ultimately
a deconstructionist language (as Larry has pointed out), which leads me
down the path of deconstructing *it*.
Hmm... why is it that Perl brings out the religious and social metaphors
for me? ;)
--
Aaron Sherman <[EMAIL PROTECTED]>
This message (c) 2003 by Aaron Sherman,
and granted to the Public Domain in 2023.
Fight the DMCA and copyright extension!
