Mind the difference between reference and value types!

[Dan Sugalski]

I notice that the type coercion thread seems to be getting value and
reference types mushed together, which strikes me as potentially an
issue.

If, for example, you have this code:

$a = new Foo;
$b = $a;
$a.make_my_string("bar");
$b.make_my_string("foo");
print "$a $b";

If Foo is a reference type that prints "bar bar" while if it's a
value type it prints "foo bar". It may potentially affect how
assignment happens as well. (If Foo is a value type its FETCH/STORE
methods may take hold on assignment, while if it's a reference type
then they may not, for example)
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Me]

> If, for example, you have this code:
>
> $a = new Foo;
> $b = $a;
> $a.make_my_string("bar");
> $b.make_my_string("foo");
> print "$a $b";
>
> If Foo is a reference type that prints "bar bar" while if it's a
> value type it prints "foo bar".

I could understand "foo foo" (ref) or "bar foo" (value),
but you've got sorta the exact opposite. Is that a "typo"?

--
ralph

[Dan Sugalski]

D'oh! Yes, a typo. Should be "foo foo" for the ref version and "bar
foo" for the value version...

[Michael Lazzaro]

On Thursday, April 17, 2003, at 10:10 AM, Dan Sugalski wrote:
> I notice that the type coercion thread seems to be getting value and
> reference types mushed together, which strikes me as potentially an
> issue.
>
> If, for example, you have this code:
>
> $a = new Foo;
> $b = $a;
> $a.make_my_string("bar");
> $b.make_my_string("foo");
> print "$a $b";
>

> If Foo is a reference type that prints "foo bar" while if it's a value
> type it prints "bar bar". It may potentially affect how assignment

> happens as well. (If Foo is a value type its FETCH/STORE methods may
> take hold on assignment, while if it's a reference type then they may
> not, for example)

<edited to fix typo>

Sorry 'bout that, I was trying to ignore that distinction until I/we
understood enough about typed/untyped transitions in general. But
you're right, it will affect the rules for assignment, simply by virtue
of things potentially cloning themselves vs. not.

The frequently too-invisible diff between value types and reference
types is, in my mind, one of the biggest flaws of current OO coding.
But I don't know how to solve it, and I don't know anyone else who's
solved it, so I guess we just have to live with it. I saw your
previous p6i posts on the subject... yeah, what you said.

MikeL

[Paul]

--- Dan Sugalski <d...@sidhe.org> wrote:
> I notice that the type coercion thread seems to be getting value and
> reference types mushed together, which strikes me as potentially an
> issue.
>
> If, for example, you have this code:
>
> $a = new Foo;
> $b = $a;
> $a.make_my_string("bar");
> $b.make_my_string("foo");
> print "$a $b";
>
> If Foo is a reference type that prints "bar bar" while if it's a
> value type it prints "foo bar". It may potentially affect how
> assignment happens as well. (If Foo is a value type its FETCH/STORE
> methods may take hold on assignment, while if it's a reference type
> then they may not, for example)

Good point. Aren't objects still references? That would mean assigning
the *value* of $a to $b would assign a reference to the same object.
If so, $b = $a shouldn't dereference because it's scalar to scalar.
I'd say that would make it an alias (but it would print "foo foo", not
"bar bar". :)

Still, what I've been thinking with most of my examples was something
like
my Foo $f = Bar.new; # assuming Bar subclasses Foo

which I assume assigns the reference to Bar into $f. Yes?

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

[Austin Hastings]

--- Dan Sugalski <d...@sidhe.org> wrote:

> I notice that the type coercion thread seems to be getting value and
> reference types mushed together, which strikes me as potentially an
> issue.
>
> If, for example, you have this code:
>
> $a = new Foo;
> $b = $a;
> $a.make_my_string("bar");
> $b.make_my_string("foo");
> print "$a $b";
>
> If Foo is a reference type that prints "bar bar" while if it's a
> value type it prints "foo bar". It may potentially affect how
> assignment happens as well. (If Foo is a value type its FETCH/STORE
> methods may take hold on assignment, while if it's a reference type
> then they may not, for example)

How will that be handled? Is it the case that there is going to be (by
default) *one* multi infix:=($a, $b) {...}, with good performance, or
will there be several such definitions out of the box, with the
expectation that multidispatch will be fast enough to work?

If we use the "simpler/faster" assignment operator, then we should get
one function that looks for a FETCH and a STORE if available.
Otherwise, we just get reference semantics. That is, if I say:

class String is Str {
method scramble($self) {...}
}

And then say:

my $a;
my $b = String.new("blah");
$a = $b;

I would expect that since String.FETCH doesn't exist and String.STORE
doesn't exist, I'll just get (Scalar $a) = (Scalar $b), which is
copying the Ref-to-String from one place to another, right?

=Austin