David Grove wrote:
...
> This is frightening me too. I really don't like the thought of
>
> $i = "1.0";
> $i += 0.1 if $INC;
> $i .= " Foo, Inc.";
>
> (or more specifically a one line version that converts several times for a
> single statement)
>
> becoming
>
> my str $i = "1.0";
> if($INC) {
> $i.asFloat += 0.1;
> }
> $i.asString .= " Foo, Inc.";
>
> We appear to be moving in that direction, trading programmer convenience
> with politically correct verbosity.
that isn't what I suggested.
With references-in-scalars, the p5 status quo, there's no hint at all what
$R refers to. It might not be a reference, but it might be a "genuine"
scalar, holidng a number or some text. You can't deny this is a confusing
state of affairs. I have no idea if
print $R
is going to give me a reasonable output or some internals-debugging noise.
We even have the C<ref> operator to help us with this problem
sub deref($);
sub deref($){ref $_[0] ? deref $$_[0] : $_[0]);
print deref $R;
So why not, since the $ preceding the name of a reference doesn't do
a whole lot, let's deprecate it?
1 @$R
2 @{$R}
3 @{R}
4 @{&R}
5 @{'R'}
6 @R
How much difference does it make, in situations where these
are all defined, 6/3 starts binding to 4 rather than 5?
You know, we have it (undecorated variablkes) already, if we don't mind
always using
curlies around variable names, we can create subroutines to return
references for
each and every variable.
my Dog spot;
could, in p5 terms, be short for something like this:
{
my $obj = new Dog;
sub spot { return $obj }
};
This is the exact same discussion from October 2000. :)
