From: Xavier Noria Date: 2010-11-13T19:00:34+09:00 Subject: Re: what's an object? On Sat, Nov 13, 2010 at 10:09 AM, Yukihiro Matsumoto wrote: > In message "Re: what's an object?" >    on Sat, 13 Nov 2010 15:13:54 +0900, Xavier Noria writes: > > |PS: I have to say that those arrows and boxes match the observed > |behavior and MRI implementation, but the spec as far as I can tell > |does not imply them with 100% confidence in my opinion. > | > |I do believe that's what the spec *wants* to specify, but the word > |"reference" is not used, and the verb "copy" does not appear either. > |My interpretation is that the first is there via the verb "refers", > |and the fact that variables are not objects. And that in method > |invocation "copy" is obviated because we are dealing with pointers and > |the mere described assignment is enough. I've written to Matz about > |this. > > So you guys seem to agree with the basic concept.  From CRuby > implementation stand point, variables are fundamentally pointer to the > object (region within a heap), with some exceptions of immediate > values.  In that sense, Xavier's description is correct.  But we > haven't choose to use those terms in the standard description, just > because the spec should not assume particular implementation detail. > On some alternative implementation, the object might be represented by > mere number, or combination of pointer values. Excellent. Then, at the spec level, we can assume that conceptually variables hold references, whose implementation may vary, and that they refer to objects. It belongs to the public contract of the language that a variable does not store an object, and that v.foo asks the interpreter to send a "foo" message to the object the variable v refers to. I mean, that's the real and public contract. One can speak informally about sending a message to v, but when you need to be rigorous about the formalities of the language (eg in the context of this thread to explain why Ruby has pass-by-value semantics) the reference in v has an unspecified implementation, but it is conceptually explicit.