> There is a fundemental issue on how values are passed between
> threads. Does the value leave one thread and enter the other or are
> they shared.
> The idea tossed around -internals was that a value that crosses a thread
> boundary would have a wrapper/proxy attached to handle the mediation.
Think of it this way: you're asking that when you write
return WHATEVER;
(for various values of WHATEVER) that *sometimes* it's context
dependent, and sometimes it's not. Right now, it always is,
which is more consistent, predictable, and explainable than the
alternative.
Or maybe you're a
>>> sub fn { return (3,5,7) }
>>> $x = fn;# I want $x==3
>Let me try once more. I want that fn() to act like
> sub fn { my @a = (3,5,7); return @a}
Oh. You want lists to act like arrays. That's a very big change.
>You are letting the scalar context of the caller to bleed through the re
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want to jam a list into anything. I want it to remain a list.
TC> Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
TC> A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
>> sub fn { return (3,5,7) }
>> $x = f
>I don't want to jam a list into anything. I want it to remain a list.
Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
> sub fn { return (3,5,7) }
> $x = fn;# I want $x==3
Why should it return the first o
I was wondering, should there be a split between the name and the
contents?
So that
my $a :shared;
my $b;
$b = $a = &fn;
So that access through $a is mediated. Access through $b is "don't do that".
Should perl take on the responsibility of coddling the user?
Perhaps a
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> I don't want that to change. I simply want that return (I'm not sure
>> how to phrase this) be able to return only a scalar or an aggregate.
TC> die unless wantarray;
Okay, I'll admit it, again. I find the changing of a comma in what
