Type/Class Unification in Ruby

[Greg Ewing]

Clemens Hintze wrote:
> 
> But it is worth mentioning, that Ruby features
> single inheritance *by*purpose*. Not because of the implementation
> details!

I wasn't making a value judgement, only pointing out that
Ruby's solution is as simple as it is because of this
restriction. 

> If it would implement multi-inheritance, the class structure could
> e.g. use an array of pointer to all such C structs, not only one
> pointer, as implemented now!

Sure, Python could do something like that too. But it would
get very hairy and complicated and probably slow everything
down a lot, casting doubt on whether it's worth the effort.

A middle ground might be to allow inheriting from any number
of user-defined classes, but at most one built-in type.

> The second (preferred) way is, to build instances of class DATA
> wrapping the C struct you have allocated for your extension.

Yes, I know, but what I was saying still applies in that case.
All the methods of the extension class expect the DATA object
to be pointing to their own particular kind of struct, and
because of the inheritance structure, this is always true --
so they don't need to bother checking.

> Deriving a Ruby class coded in C from another one also coded in C,
> seems to be the only right tricky part of that language, IMHO. :-)

I think it will work as long as the derived class makes sure
that its C structure is an exension of the superclass's C
structure.

>     Greg> [global instance var dict] might cause ref counting
>     Greg> problems.
> 
> Once again, thanks for Ruby's true garbage collection! :-)

Garbage collection alone doesn't actually solve the problem;
the references from the global dict need to be treated as
weak references somehow under either scheme. I haven't
looked, but presumably Ruby must be ignoring the global dict
refs when marking, and cleaning them up whenever a builtin
or extension object is deallocated. Python could be made to
do the equivalent.

> The big exception,
> AFAIK, was class Fixnum. It never had any instanciation method, as it
> doesn't wrap any struct.

Yes, that's the one class you really can't instantiate a
subclass of, since its class is totally implicit.

But it's not clear whether it's any use having something
like a UserFlonum, either, even though technically it could
be done. Unless you override every method, any arithmetic
on it would return an ordinary Flonum. And if you are going
to override every method, it might as well be a totally
new class!

> Often it is better to use the module
> mechanism to add methods to class Array or some of its instances
> during runtime.

You mean you can add methods to an *existing* class that
way? Not sure if I like that idea...

Greg