--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> >>The design team has already considered this idea, and my problem
> >>with it then (and now) is that it's inconsistent with other forms
> >>of variable declaration:
> >>
> >> my sub foo( ?$bar is constant = 1 ) {...} # OKAY
> >> my $bar is constant = 1; # OKAY
> >>
> >> my sub foo( ?$bar = 1 is constant ) {...} # OKAY
> >> my $bar = 1 is constant; # KABOOM!
> >>
> >>and thereby lays a cognitive trap for programmers.
> >
> >
> > 1- Good catch, and all, but that's the kind of thing (like @ in
> > strings) that gets a warning emitted from the compiler -- not the
> kind
> > of thing that makes it prohibitive to support the feature.
>
> Quite possibly. Except that, the more of these kinds of cognitive
> dissonances
> a language has, the harder it is to learn and use. I see part of my
> job as
> being to keep an eye on how many such special cases we're adding (and
>
> removing!) from Perl 6. With the goal that the overall cognitive load
> of the language doesn't go up.
But this isn't really a cognitive dissonance, so much as perl6 being
willing to forgive ordering in cases where the meaning is obvious.
I HOPE this doesn't work:
my sub foo( ?$bar = 1 is constant ) {...} # OKAY, but redundant.
my sub foo( ?$bar is rw = 1 is constant) {...} # const if defaulted?
Unless the second case works, and I hope it doesn't, there's only one
meaning to "is <trait>" in a signature. Since there's only one meaning,
just warn the developer if the order doesn't agree with declaration
order.
> >>I don't know...maybe I'm worrying too much.
> >>But then, that's part of my job. ;-)
> >
> > 2- Yeah! ... umm, are we *paying* you for this?
>
> Not any more. In fact, like Larry and several others on the design
> team, I'm now paying for the privilege of doing it. ;-)
You're a point of light, Damian. (*)
=Austin
*: Borrowed from the "other" George Bush.
