On Fri, Feb 03, 2006 at 12:41:47PM -0800, Dave Whipp wrote:
: Larry Wall wrote:
:
: >But that's just my current mental model, which history has shown
: >is subject to random tweakage. And maybe "env $+result" could be a
: >special squinting construct that does create-unless-already-created.
: >Doesn't feel terribly clean to me though. If we stick with the +
: >twigil always meaning at least one CALLER::, then clarity might be
: >better served by
: >
: > env $result := $+result // 1;
: >
: >assuming that $+result merely returns undef in the outermost env context.
:
: Wouldn't that bind $result to a constant at the outermost scope -- and
: therefore to that same constant in all inner scopes? If so, then later
: attempts to assign $result would be an error.
Hmm, well, it wouldn't work anyway since env variables are readonly
by default outside their "my" scope. I ought to at least have said
env $result is rw := $+result // 1;
As for
my $answer := 42;
I would hope that binding a constant to a rw location is smart enough
to make an anonymous rw copy (or COW). I think that's what most
existing Perl programmers would expect. I'm sure a C++ programmer would
argue it the other way though.
But whichever way that goes, certainly if you want to make $answer
a constant, the current design encourages you to do it explicitly with
constant $answer = $mumble;
rather than as an accidental side effect of binding a value that just
happens to be a constant. And I think a good argument can be made that
my $foo := "some text";
is a great way of sharing "some text" among all default instances of $foo,
whereas
my $foo = "some text";
would be required to force a copy, at least in the abstract.
Of course, the existence of a COW string implementation can be taken
as an argument either way. It really kind of depends on whether you
see "some text" as an object or as primitive data that autoboxes when
a container reference is requested.
Larry
