On Friday 16 February 2001 09:24, Branden wrote:
> I said:
> > Anyway, I don't see why `local' (and `our' and `my') should bind more
> > strongly than , and = .
Because the implicit global scope declarator binds that tightly.
Because you lose the ability to mix scope declarators in an assigment.
(my $a, $b, local $,, my $c) = @_;
I suppose the counter argument is you could then write that as
(my($a),our($b),local($,),my($c)) = @_;
Surely that would then allow
(my $a, $b, $c) = @_;
to be the same as
my ($a,$b,$c) = @_;
Oh, wait, commas are now implicitly parenthesized, so that
(my $a, $b, $c) = @_;
can be written as
my $a, $b, $c = @_;
That's going to affect some compound expressions, but those can easily be
fixed by liberal uses of the 'scalar' operator, er, function, er, term.
Oh, wait. That also doesn't behave quite right. That can also be tweaked,
I'm sure.
But what does that give you?
You've now taken several existing behaviors of the language and completely
changed it for no *net* improvement to the language. (Okay, that may be
subjective, but feel free to argue how what you've added significantly
outweighs a) what you've changed, and b) the fact that you changed it.)
Now, admittedly, I've not done very much language design, but even in
generic software design:
- you think hard before adding functionality, and that added functionality
had better provide a net improvement to the product,
- you think even harder before removing functionality, and that the removal
of functionality had better provide a larger net improvement to the product,
- you do a complete brain drain before changing existing functionality, and
that change had better provide a huge net improvement to the product,
- you don't make any of these decisions arbitrarily.
--
Bryan C. Warnock
[EMAIL PROTECTED]
