From: Michal Suchanek <hramrach@...>
Date: 2009-02-16T07:24:03+09:00
Subject: [ruby-core:22169] Re: A short memorandum (Re: 1.8.7 Specifics)

2009/2/15 Charles Oliver Nutter <charles.nutter@sun.com>:
> 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.

What I have seen proposed is splitting into one extension per
implementation with possibly overlapping but different sets of
methods. I find this uglier than having just everything lumped
together.

>
> 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.
>

They are specific to particular kind of GC, not to MRI.

Thanks

Michal