not the address of the variable but the object (or a copy of the
object) itself
when I really meant:
not the address of the variable but rather the address of the object
and had over-simplified it to something like:
not the address of the variable but the object
which is syntactically ambiguous.
Paul
···
On Fri, Oct 05, 2007 at 11:05:23PM +0900, Robert Klemme wrote:
2007/10/5, Paul Brannan <pbrannan@atdesk.com>:
> On Fri, Oct 05, 2007 at 04:50:04AM +0900, Robert Klemme wrote:
> > >Under strict interpretation of this definition I think Ruby is not
> > >call-by-reference, since the address of a variable is never passed, but
> > >rather the object to which the variable refers.
> >
> > Not the object is passed but the address / handle or however you want to
> > name it. If it were the object we'd have call by value IMHO (objects
> > are values in Ruby).
>
> Perhaps I wasn't clear. I meant:
>
> > >Under strict interpretation of this definition I think Ruby is not
> > >call-by-reference, since the address of a (variable is never passed, but
> > >rather the object)...
I'm sorry, but now I'm confused. Either I originally understood what
you meant or I'm missing something in the new version. Maybe it's
time to leave the office and have a nap...
In PHP 4 and 5 you have references which work similar like C++
references. E.g. you can make a variable reference another variable
after which if you change the value of one of those variables the other
variable's value will also be "updated".
...
However, in PHP 5 they introduced a concept similar to the "references"
we know in Ruby. But because they already used the term "reference" they
had to come up with a different name, so they call them object handles.
...
So maybe we should call them handles instead of references to clarify
the difference?
I don't know how it relates to PHP 5, but historically object handles
meant something different.
One way to implement an object memory/heap is to use a level of
indirection, an object is represented by what's effectively an element
in an array of pointers, with the pointer holding the address of an
object's state. Variables refer not to the object directly but to the
pointer, which is called a handle. This allows the objects to be
moved (during GC for example) without requiring all references to the
object to be relocated.
Two uses of object handles were in the earliest implementations of
Smalltalk, and in the old Macintosh OS.
I prefer the term Object Reference myself, and see Object Handle as a
particular implementation (at least as the term applies to the systems
I just described).
···
On 10/2/07, Peter C. Verhage <peter@no-nonsense.org> wrote:
> <snip>
> > Part of the problem with this whole discussion is that it's crossing
> > meta-levels. Immediates/intrinsics exist in the implementation, below
> > the language level. To the Java/Smalltalk/Ruby programmer the
> > encoding of object references is invisible. Object references are
> > object references.
> Not for Java - we can not accept Java in the same league as Smalltalk
> and Ruby can we ? ;).
Um, where's the problem? Java is a great language and it certainly
has its uses (helps to pay my bills for example). And don't forget
that several pieces of Ruby were inspired by Java (at least I believe
so).
There was a Smiley Robert, however I feel that Smalltalk and Ruby are very much
in contrast to Java. Java is a nice tool but it is not a dynamic
language and it is not
pure OO. This might not be important for many, for me it is.
> While in Smalltalk and Ruby I can and shall handle a Fixnum as an
> imutable object
> in Java I cannot.
> IIRC this fact is somehow hidden in version 1.5+ by some mechanism of
> Autoboxing but I am not sure about that.
Immutability and PODs with autoboxing are different concepts. In all
Java versions (i.e. even prior to 1.5) java.lang.Integer and similar
/are/ immutable. In fact, with regard to calling semantics this is
the exact equivalent to Ruby.
Yup, maybe I missunderstood here, I was not talking about java.lang.Integer but
about int. Probably my error. What I wanted to clarify was that in
Java is int,bool etc which are not objects even on the language level.
It might however be that this is not related to the discussion as I
thought first.
Always good to talk it over
From a Ruby language user's perspective
immediate values are just an internal optimization that is irrelevant
for parameter passing modes. Rick nicely pointed this out.
As he often does but this time I seem to have it missread :(.
Robert
···
On 10/5/07, Robert Klemme <shortcutter@googlemail.com> wrote:
2007/10/5, Robert Dober <robert.dober@gmail.com>:
> On 10/5/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
I think the JVM does (or did) something similar using an intermediate object table.
-- fxn
···
On Oct 3, 2007, at 5:23 AM, Rick DeNatale wrote:
One way to implement an object memory/heap is to use a level of
indirection, an object is represented by what's effectively an element
in an array of pointers, with the pointer holding the address of an
object's state. Variables refer not to the object directly but to the
pointer, which is called a handle. This allows the objects to be
moved (during GC for example) without requiring all references to the
object to be relocated.
Two uses of object handles were in the earliest implementations of
Smalltalk, and in the old Macintosh OS.
I see using a memory address as a particular implementation of a
"handle". I was thinking that the term "pointer" may be good enough,
but most think of a pointer as a memory address.
The problem with the term "reference" is that in the context of
call-by-reference, it implies something closer to an alias (arguments
of the function refer to the lvalue that the function was passed). In
that context, if a variable is an object reference, "a = b" would be
equivalent to a.become(b), which is definitely not what ruby does.
In the context of the original discussion (call-by-*), call-by-handle
seems like a good description for ruby. Variables simply hold object
handles.
···
On 10/2/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
I prefer the term Object Reference myself, and see Object Handle as a
particular implementation (at least as the term applies to the systems
I just described).
> > Not for Java - we can not accept Java in the same league as Smalltalk
> > and Ruby can we ? ;).
>
> Um, where's the problem? Java is a great language and it certainly
> has its uses (helps to pay my bills for example). And don't forget
> that several pieces of Ruby were inspired by Java (at least I believe
> so).
There was a Smiley Robert,
Yes, I know I know. But I'm sick of all the Java bashing around and
had to voice that at some point. <rant>I often get the impression
that some dynamic language adopters feel like they are the avantgarde
or elite and disregard other tools just because they are not the
newest / hottest / whatever.</rant> Note, I don't mean you - you just
happened to provide the trigger.
however I feel that Smalltalk and Ruby are very much
in contrast to Java. Java is a nice tool but it is not a dynamic
language and it is not
pure OO. This might not be important for many, for me it is.
Admittedly it has it's advantages and actually this is one of the
reasons I love Ruby - everything is an object - period. There are no
exceptions and this is really great.
Kind regards
robert
···
2007/10/5, Robert Dober <robert.dober@gmail.com>:
On 10/5/07, Robert Klemme <shortcutter@googlemail.com> wrote:
> 2007/10/5, Robert Dober <robert.dober@gmail.com>:
Yep, but that's not relevant to the kind of method call done by Java. The point is: no matter whether you have a primitive int or an object reference, in Java they are passed by value. The JLS says[*]:
When the method or constructor is invoked (§15.12),
the values of the actual argument expressions initialize
newly created parameter variables, each of the declared
Type, before execution of the body of the method or
constructor.
Yup, maybe I missunderstood here, I was not talking about java.lang.Integer but
about int. Probably my error. What I wanted to clarify was that in
Java is int,bool etc which are not objects even on the language level.
Perhaps, but I don't think that its a widely used implementation
strategy these days. The main advantage seems to be that it's a
little easier to understand than more modern GC architectures. On the
other hand it tends to limit the total number of objects because of
the need for an object handle table.
One of the things which the early Smalltalk memory management design
did was to enable the become method. In Smalltalk one could say:
object1 become: object2
and the objects referenced by object1 and object2 would swap
identities, kind of a 'Freaky Friday' effect Freaky Friday (2003) - IMDb This was used mostly to allow
collection objects to be resized.
To get around the limitations of a fixed size object table, it became
standard practice to let the handles exist in the heap along with the
objects, or perhaps in a separate heap. The handle contained a
pointer to the bulk of the object and a few bit fields used for GC and
other housekeeping.
These days it's much more common to find object references to be
direct pointers with bit tagging to identify special immediate
references, and the non-pointer contents of the handle moved into
header fields in non-immediate objects. The need for become: in
Smalltalk was obviated by refactoring the collection classes to hold
their contents in a separate array so that resizing could be done by
copying the contents array to a larger array rather than copying self
to a larger version and doing self become:largerSelf at the same time
the semantics of become: changed from the two-way swapping to a
one-way version which scanned object memory for references to the old
object and changing them to point to the new.
Many modern GC designs move objects during GC, and some of these still
use indirect forwarding pointers to a limited extent, usually
temporarily during GC.
···
On 10/3/07, Xavier Noria <fxn@hashref.com> wrote:
On Oct 3, 2007, at 5:23 AM, Rick DeNatale wrote:
> One way to implement an object memory/heap is to use a level of
> indirection, an object is represented by what's effectively an element
> in an array of pointers, with the pointer holding the address of an
> object's state. Variables refer not to the object directly but to the
> pointer, which is called a handle. This allows the objects to be
> moved (during GC for example) without requiring all references to the
> object to be relocated.
>
> Two uses of object handles were in the earliest implementations of
> Smalltalk, and in the old Macintosh OS.
I think the JVM does (or did) something similar using an intermediate
object table.
On 10/3/07, Eric Mahurin <eric.mahurin@gmail.com> wrote:
On 10/2/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> I prefer the term Object Reference myself, and see Object Handle as a
> particular implementation (at least as the term applies to the systems
> I just described).
I see using a memory address as a particular implementation of a
"handle". I was thinking that the term "pointer" may be good enough,
but most think of a pointer as a memory address.
The problem with the term "reference" is that in the context of
call-by-reference, it implies something closer to an alias (arguments
of the function refer to the lvalue that the function was passed). In
that context, if a variable is an object reference, "a = b" would be
equivalent to a.become(b), which is definitely not what ruby does.
In the context of the original discussion (call-by-*), call-by-handle
seems like a good description for ruby. Variables simply hold object
handles.
--
Rick DeNatale
Fine Object Oriented Programming since the 1980s
yes I feel that Smalltalk and Ruby are conceptional better than Java.
Java is a language that just is not at the same level.
It does not really satisfy the expression Very High Level, it is not
even half as expressive and elegant as S&R.
I do not feel I bash Java, I just think it is a different thing and overrated.
I am aware that this opinion might hurt some feelings and that is why I kind
of held back. But I guess you have seen through me Robert so I better confess
right away.
Robert
···
On 10/5/07, Robert Klemme <shortcutter@googlemail.com> wrote:
2007/10/5, Robert Dober <robert.dober@gmail.com>:
> On 10/5/07, Robert Klemme <shortcutter@googlemail.com> wrote:
> > 2007/10/5, Robert Dober <robert.dober@gmail.com>:
> > > Not for Java - we can not accept Java in the same league as Smalltalk
> > > and Ruby can we ? ;).
> >
> > Um, where's the problem? Java is a great language and it certainly
> > has its uses (helps to pay my bills for example). And don't forget
> > that several pieces of Ruby were inspired by Java (at least I believe
> > so).
> There was a Smiley Robert,
Yes, I know I know. But I'm sick of all the Java bashing around and
had to voice that at some point. <rant>I often get the impression
that some dynamic language adopters feel like they are the avantgarde
or elite and disregard other tools just because they are not the
newest / hottest / whatever.</rant> Note, I don't mean you - you just
happened to provide the trigger.
Yep, it looks like Squeak has both ProtoObject#become: which has the
old swap semantics, and Object#becomeForward: which is one-way.
A quick look at the senders of #become: in the standard 3.9 image
seems to indicate that none of them actually use the swap they are all
becoming a newly created and otherwise unreferenced object, which
won't be referenced when the method returns.
···
On 10/3/07, Robert Dober <robert.dober@gmail.com> wrote:
On 10/3/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
<snip>
>
> One of the things which the early Smalltalk memory management design
> did was to enable the become method. In Smalltalk one could say:
>
> object1 become: object2
>
Squeak still does support this.
When used with care it can be a wonderful tool, especially in metaprogramming.
