I'm missing what you are trying to say. Are you suggesting that
$foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ?
I wasn't suggesting going that far. Just a little more DWIM.
So that
($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef
# or
# $foo = 1 @bar=(2), $baz = 3
($foo, @bar, $baz) = (1,(2,3),4) # $foo = 1 @bar=(2,3), $baz = 4
But
($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4)
Actually, looking at it like that makes it an ugly situation. The 'new'
expectation would be to have it become
# $foo=1 $baz=2 @bar=(4)
*blech*, I'm glad that you're doing the thinking.
<chaim>
>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Chaim Frenkel writes:
LW> : LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar
LW> : LW> context, as long as the object returned overloads itself to behave as
LW> : LW> arrays and hashes currently do in scalar context.
LW> :
LW> : Isn't this an internals issue?
LW> Not completely. The scalar value would visably be a built-in object:
LW> @bar = (0,1,2);
LW> $foo = @bar; # now means \@bar, not (\@bar)->num
LW> print ref $foo, $foo->num, $foo->str, ($foo->bool ? "true" : "false");
LW> ^D
LW> ARRAY3(0,1,2)true
LW> One implication of this approach is that we'd break the rule that says
LW> references are always true. Not clear if that's a problem. It's basically
LW> already broken with bool overloading, and defined still works.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
