Just for future, as this gives us a way to know immediately in the type, which represent normal, and which singleton classes
Also instantiate singleton class lazily (with singleton type)
This makes the type of class single, ie unique, immediately when it is used, ie methods or variables defined.
Fixes a design mistake, where all singletonn classes shared the same type, and thus unique methods per class were impossible
(Also some misc in commit)
resolve had the wrong approach, sort of class based oo
It took methods from "derived" types and just used them
To be correct, those methods would have to be recompiled for the current type, rubyx is type, not class based.
Started on that, still soe strange hang though
Later, type and method analysis may reveal "compatible" types (down only off course) where one could use the exact same code, but that is phase 2
seems more appropriate, as it is the class for a single object
Also seems to be called that on the net (don't remember where the meta came from, but it's gone)
after some serious recursive thinking it now actually makes sense.
The key was to change the actual type of the class that the meta_class manages
For objects it's (still) ok just to change the instance_type, but since the class object exists and has type, when adding instance variables, that actual type has to change
as they are just the type of the meta_class, that was relatively simple.
I feel this is what oo is meant to be, instance variables and methods for the objects, and since classes are objects, for them too.
Class variables seem like a design mistake, weird scoping rules and no data hiding (left as an exercise to the reader)
previous commit affected rather many test, as the implicit returns add extra instructions
Also added some explicit returns, so as not to test the return logic too much. return (ie return nl) is a knonwn 3 risc operation.