(Hopefully the brain cannot be permanently damaged by excessive pondering)
Gary Wright wrote:
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).
Alas, my problem now is, that an assignment for my CS class requires me to prove that the obj is an instance of the singleton. (And no, it's no trick question, the teacher has even lectured about it and proposed a solution at the labs--- which btw I don't buy).
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.
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
···
On Feb 17, 2008, at 4:09 AM, UpsNDowns wrote:
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.
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.