object specific methods and id

[UpsNDowns]

(Hopefully the brain cannot be permanently damaged by excessive pondering)

I suppose but then you have to explain why the singleton class didn't
provide a masking implementation of its own superclass method, which
you don't want it to do since that would break
various other semantics in particular the behavior of singleton
classes of classes and method lookup on class instances.

Come to think of it, isn't this how things are in ruby 1.9? (At least
this is how I read Christophers post in this thread).

Kind regards

 

[UpsNDowns]

Well, prove the teacher wrong showing that their definition of
'instance of' is ambiguous. You could take a test driven approach
and write some tests that describe the expected behavior of a class
and its instance. Then try the tests against different types of
objects:

1)
Looking at the ruby code (the C) it appears that the teacher may be
right in a technical sense. Fx the 'rb_class_real' method of object.c
'peels' off any singletons before returning the class of an object.

(However that is also odd as the singletons get special help from the VM
that goes beyond their creation. In a clean solution, I *guess*, the
singletons could be completely ordinary classes once they're made).

2)
I suspect this is the real reason Mr. Black was so vague on the
implementation of the singletons, in the slides I refered to earlier on.
Perhaps singletons really are implemented as a subclass, put it's not
the ruby way to think of it that way.

Kind regards

 

[Gary Wright]

1)
Looking at the ruby code (the C) it appears that the teacher may be
right in a technical sense. Fx the 'rb_class_real' method of
object.c 'peels' off any singletons before returning the class of
an object.

(However that is also odd as the singletons get special help from
the VM that goes beyond their creation. In a clean solution, I
*guess*, the singletons could be completely ordinary classes once
they're made).

I'm not sure why you keep switching the point of view (current
implementation, possible alternate implementation, language-level).
I've been writing in the context of what a Ruby programmer is able to
see not what an implementer can or might be able to see.

Gary Wright

 

[UpsNDowns]

Hi Gary,

I'm not sure why you keep switching the point of view (current
implementation, possible alternate implementation, language-level).
I've been writing in the context of what a Ruby programmer is able to
see not what an implementer can or might be able to see.

Well for three reasons. The premier is that Im confused about this and
hence lack a clear-cut view of things and in effect grab onto every
straw, that appears helpful at the moment.

Another is (or rather was I suppose) that I was unable to find a more
formal/precise specification of what ruby is (it may exist but I haven't
found it). Also, I came across webpages claiming that ruby doesn't
have such a formal specification. If this is true then ruby is defined
by what the current implementation does (this may change once I get the
ruby-way internalised, I suppose).

The final reason was to try to discover the boundary between the ruby
programmer and the VM. Eg to answer questions like the following: it's
possible to 'overwrite' the class method, but does that change the
methods/messages that an object implements, if not why, if it does why?

I really appreciate your (and the rest of posters) help.

Kind regards.