Michal Suchanek wrote:
> And if you are dealing with different versions of the same
> implementation that may or may not implement some of the methods then
> what?
> 
> And if you start a new ruby implementation that has GC somewhat
> similar to one of the other ones, but missing some methods, what then?
> 
> Similarly, if two implementations have a similar GC but not quite the same?
> 
> It's always ugly, and splitting the ugliness into several separate
> modules does not seem to help here.

Splitting them into at least one extension would at least isolate it. 
You'd have to willingly opt into having those methods available.

Look at it this way. String has no methods any implementation couldn't 
support with some effort. Nothing about String is implementation 
specific. The same goes for Array, Hash, and almost all the other 
"default" core classes. That's what I see as the core set of Ruby APIs.

GC starts to leak implementation details to that public set, and since 
they're always present without loading an extension or library, they 
generally get lumped in with that core set, even though they'll be 
implementation-specific.

I don't understand why there's resistance to just making them live in an 
extension. They're very MRI-specific.

- Charlie