Object semantics
Dan Sugalski
and then digging into the vtable split stuff, but I thought I'd
specify at least a little how objects (this would be real
language-level "we're object-oriented dammit!" objects, not the
lower-level stuff we're currently working with) should/will behave.
Parrot, like all the OO languages that will live on top of it, uses
reference-style objects and non-reference values. The difference here
is that on assignment values are cloned and references are copied. If
you do this:
a = b
and b is a value, a will have a copy of the value in b, but it'll be
in a different location in memory, and changes to b won't affect a.
On the other hand, if b is an object, then a and be refer to the same
object, and actions on either a or b affect the other. (This is nasty
action at a distance, and I really don't like it, but nobody asked me
here :)
We are going to muddle things some by having value objects in
addition to reference objects, as arguably all the values that are in
PMCs can be treated as value objects. (When those PMCs hold
references to reference objects, the copied value is just an address
so the destination object, and thus our value objects handle the case
of being the front half of a reference object just fine)
Still, for 'real' OO, it's all reference object stuff, so things
should Just Work. The pending questions about ruby assignment work
out since, while the assignment part of vtable behaviour's
potentially troublesome, it doesn't make any difference since what
you're assigning into is the front half of a reference object, and
thus you get pointer-to-pointer semantics the way you want. (And if
it's not, then it should do the right thing on assignment, which may
be... interesting in a mixed-language environment)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> Still, for 'real' OO, it's all reference object stuff, so things should
> Just Work. The pending questions about
... strings still is pending ;-)
Remember string_set ins substr and 50% live performance increase.
Do we want do reuse string headers like PMCs (and change semantics
slightly) or do we not.
And: Subject "GC quick note"
One thing that might help the GC situation some.
Since we've got mutable strings (yep, it's OK) perhaps we should
thump the string functions a bit to not allocate new strings quite so
often. That'll leave us fewer headers to worry about.
--
Dan
leo
Gopal V
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
> reference-style objects and non-reference values.
How large can a non-reference value be ? ... (in the .NET opcodes the
'struct' seems to be unlimited in size ...) But well, I'd settle for
a non-reference of at least large integers (64bit)...
And how will non-reference values dispatch methods ? ... would they be
"boxed" into a reference for each method call, so that the method call
can modify them ? ...or are all non-reference values immutable ?....
to put it down clearly ...
MyValueType a;
a.Modify();
would a be able to modify itself ? (unfortunately C# allows that)
Gopal
--
The difference between insanity and genius is measured by success
Erik Bågfors
> If memory serves me right, Dan Sugalski wrote:
> > language-level "we're object-oriented dammit!" objects, not the
> > lower-level stuff we're currently working with) should/will behave.
>
> yay ! ... finally !
The moment we've all been waiting for :)
> > reference-style objects and non-reference values.
>
> How large can a non-reference value be ? ... (in the .NET opcodes the
> 'struct' seems to be unlimited in size ...) But well, I'd settle for
> a non-reference of at least large integers (64bit)...
>
> And how will non-reference values dispatch methods ? ... would they be
> "boxed" into a reference for each method call, so that the method call
> can modify them ? ...or are all non-reference values immutable ?....
>
> to put it down clearly ...
>
> MyValueType a;
> a.Modify();
>
> would a be able to modify itself ? (unfortunately C# allows that)
So does ruby. We need that :)
/Erik
--
Erik Bågfors | er...@bagfors.nu
Supporter of free software | GSM +46 733 279 273
fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32
Dan Sugalski
>On Sat, 2003-01-04 at 00:28, Gopal V wrote:
>> If memory serves me right, Dan Sugalski wrote:
>> > language-level "we're object-oriented dammit!" objects, not the
>> > lower-level stuff we're currently working with) should/will behave.
>>
>> yay ! ... finally !
>
>The moment we've all been waiting for :)
Sheesh, everyone lay on the guilt, why don't you? :-P
> > > reference-style objects and non-reference values.
>>
>> How large can a non-reference value be ? ... (in the .NET opcodes the
>> 'struct' seems to be unlimited in size ...) But well, I'd settle for
>> a non-reference of at least large integers (64bit)...
>>
>> And how will non-reference values dispatch methods ? ... would they be
>> "boxed" into a reference for each method call, so that the method call
>> can modify them ? ...or are all non-reference values immutable ?....
>>
>> to put it down clearly ...
>>
>> MyValueType a;
>> a.Modify();
>>
>> would a be able to modify itself ? (unfortunately C# allows that)
>
>So does ruby. We need that :)
I wasn't aware that ruby had value types--I thought it was all
reference types. Time to crack open the nutshell book again,
apparently.
Dan Sugalski
>If memory serves me right, Dan Sugalski wrote:
>> language-level "we're object-oriented dammit!" objects, not the
>> lower-level stuff we're currently working with) should/will behave.
>
>yay ! ... finally !
>
>> reference-style objects and non-reference values.
>
>How large can a non-reference value be ? ... (in the .NET opcodes the
>'struct' seems to be unlimited in size ...) But well, I'd settle for
>a non-reference of at least large integers (64bit)...
It can be as big as you like. Hang a buffer off the data pointer and
stick anything and everything you might want into it. Do we need to
build with 64 bit integers to make sure you have space? :)
>And how will non-reference values dispatch methods ? ... would they be
>"boxed" into a reference for each method call, so that the method call
>can modify them ? ...or are all non-reference values immutable ?....
Neither. Non-reference values are just plain PMCs. Reference values
are PMCs that point to other PMCs.
>to put it down clearly ...
>
>MyValueType a;
>a.Modify();
>
>would a be able to modify itself ? (unfortunately C# allows that)
Absolutely. It makes things generally faster and easier for perl, and
doesn't affect python or ruby. Yeah, I know, immutable values make a
number of static compilation things better with sufficient
engineering resources, but we're not particularly static, and our
resources are occasionally spotty. :)
Erik Bågfors
> At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
> >On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> >> If memory serves me right, Dan Sugalski wrote:
> >> > language-level "we're object-oriented dammit!" objects, not the
> >> > lower-level stuff we're currently working with) should/will behave.
> >>
> >> yay ! ... finally !
> >
> >The moment we've all been waiting for :)
>
> Sheesh, everyone lay on the guilt, why don't you? :-P
Working on it....
To be honest, I won't have much time from next week so now is probably
the only time I have to do something for a long time. So all I can do
is lay on the guilt :)
> > > > reference-style objects and non-reference values.
> >>
> >> How large can a non-reference value be ? ... (in the .NET opcodes the
> >> 'struct' seems to be unlimited in size ...) But well, I'd settle for
> >> a non-reference of at least large integers (64bit)...
> >>
> >> And how will non-reference values dispatch methods ? ... would they be
> >> "boxed" into a reference for each method call, so that the method call
> >> can modify them ? ...or are all non-reference values immutable ?....
> >>
> >> to put it down clearly ...
> >>
> >> MyValueType a;
> >> a.Modify();
> >>
> >> would a be able to modify itself ? (unfortunately C# allows that)
> >
> >So does ruby. We need that :)
>
> I wasn't aware that ruby had value types--I thought it was all
> reference types. Time to crack open the nutshell book again,
> apparently.
Well, An object can certainly modify itself.
: [bagfors@detrius]$ ; irb
irb(main):001:0> a="test"
"test"
irb(main):002:0> a.sub!('e','s')
"tsst"
irb(main):003:0> p a
"tsst"
nil
But they are still reference types.
irb(main):006:0> a="test"
"test"
irb(main):007:0> b=a
"test"
irb(main):008:0> a.sub!('e','s')
"tsst"
irb(main):009:0> p a
"tsst"
nil
irb(main):010:0> p b
"tsst"
nil
So I guess it just modifies the reference. (oh.. I really need to learn
more about low-level language-stuff...)
Gopal V
> > >> would a be able to modify itself ? (unfortunately C# allows that)
> > >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
public override String ToString(){ return val.ToString(); }
}
public class FooBar
{
public static void Main()
{
MyStruct m1=new MyStruct(10);
MyStruct m2=m1;
m1.Modify();
Console.WriteLine(m1);
Console.WriteLine(m2);
}
}
=end cut
Which gives
42
10
If in anycase Parrot wants to avoid this , we could always add a special
case to the ILNode_Assign to generate an explicit copy step in parrot for
valuetypes...
So, workarounds are possible .. and neither the host nor the compiler
is there yet ;) ...
Steve Fink
> So, workarounds are possible .. and neither the host nor the compiler
> is there yet ;) ...
Good point -- we'd better speed up on this Parrot stuff, so we can
push more of the really hard things onto you compiler guys. ;)
Dan Sugalski
Why would we want to avoid this? It looks exactly like what ought to happen.
Attriel
I think he was explaining what he meant in another post that someone
questioned, with this example; then the "wants to avoid this" referred to
"avoiding the easy-path error of NOT doing this". I think Gopal was
saying that C#/NET does it that way, and I can't imagine him asking to
have functionality he explicitly needs to be "carefully avoided" :)
OTOH, I may have misread a bunch of things, I'm not doing so hot on my
interpretations the last few days :o
--attriel
Dan Sugalski
Just because C# does it doesn't mean that he likes it. :)
Gopal V
> >> Why would we want to avoid this? It looks exactly like what ought to
> >> happen.
If you can provide that in-vm , it would be a lot faster ...(hmm, that's
one argument that should convince you ;)
But like I said , I need lots of sticky notes for all the opcodes for
parrot ...(I'm still in "can't remember all opcodes" mode)....
> Just because C# does it doesn't mean that he likes it. :)
To end all further debate --
*) C# has something like this ,
*) I can't see what Dan has in head for parrot ,
*) I don't want feature creep into parrot
*) Our C# -> JVM compiler already has the workarounds for this like:
invokestatic "MyStruct" "copyIn__" "(LMyStruct;)LMyStruct;"
*) I really don't like valuetypes that much :).
*) Rhys will be doing most of the design , this is his headache actually :-)
So does that cover all bases ?....
Dan Sugalski
>If memory serves me right, Dan Sugalski wrote:
>> >> Why would we want to avoid this? It looks exactly like what ought to
>> >> happen.
>
>If you can provide that in-vm , it would be a lot faster ...(hmm, that's
>one argument that should convince you ;)
Struct copying? Not a problem. Cloning this sort of thing is the same
as cloning off strings. Deeper copies, where we trace the tree, are a
bit trickier, but there are vtable entries to do that, so classes can
implement things as fast as possible if people need them.
>But like I said , I need lots of sticky notes for all the opcodes for
>parrot ...(I'm still in "can't remember all opcodes" mode)....
>
>> Just because C# does it doesn't mean that he likes it. :)
>
>To end all further debate --
>
>*) C# has something like this ,
>
>*) I can't see what Dan has in head for parrot ,
IIRC, it's grey and squishy. :)
>*) I don't want feature creep into parrot
If you can find a feature that we don't have, I'd be surprised. :)
There's not much left out of perl, so there's not much left out of
parrot.
>*) Our C# -> JVM compiler already has the workarounds for this like:
> invokestatic "MyStruct" "copyIn__" "(LMyStruct;)LMyStruct;"
I think we can make things a bit easier than that. We should build a
good base struct PMC type to build on to make this faster, though.
>*) I really don't like valuetypes that much :).
And I don't much like reftypes, so we're even. :)
>*) Rhys will be doing most of the design , this is his headache actually :-)
>
>So does that cover all bases ?....
I think so. I'm about ready to get objects formally(ish) defined, but
given that I'm in a coffee shop and unconnected now, it might hit the
list at the same time this does. (Or before, depending on how the
mail queues go...)
Piers Cawley
> Absolutely. It makes things generally faster and easier for perl, and
> doesn't affect python or ruby. Yeah, I know, immutable values make a
> number of static compilation things better with sufficient engineering
> resources, but we're not particularly static, and our resources are
> occasionally spotty. :)
Hey, I know some of the Parrot developers are young, but it doesn't
necessarily follow that they have acne.
--
Piers