[ruby-core:22152] Re: A short memorandum (Re: 1.8.7 Specifics)

Brent Roman wrote:
> Charlie,
> 
> All the methods in the GC module are implementation specific.
> But, the Garbage Collector is certainly an integral part of the ruby core.

I agree that the GC methods are all generally implementation-specific, 
but of course the presence of the GC module itself exposes an 
implementation detail. "GC" is not a feature of Ruby as much as 
"automatic memory management", which could be implemented in other ways. 
  Would *any* of the GC methods make sense on a reference-counted 
implementation? Very few, if any. Would a reference-counted 
implementation still fulfill "automatic memory management"? It would.

> This is why, when this issue was discussed a few week ago, I
> wrote that it would be simplest to spec only that the GC module exists
> and that what methods it supports is implementation dependent.  This works
> quite well if we standardize such that GC.start, if defined 
> always starts a GC pass.  GC.disable, if defined, always prevents
> GC until the next GC.enable.  Etc.  I'm sure you get the idea.
> 
> Applications that must interact with the GC module would be
> written in the usual Ruby ducktype fashion:
> 
>   GC.disable if GC.respond_to? :disable
> 
> Introspection is relatively cheap, simple to code and very much "the Ruby
> way"
> So, what's wrong with this?

That would be nice if that's what people did. But they don't. They just 
call the methods, and then file bugs on other implementations when they 
don't exist. I think it's been shown that having methods available on 
one implementation and not on another, or on one version and not another 
(1.8.7, eh?) ends up confusing a lot of people. Or we end up stubbing 
them out and making them do nothing, and they file bugs anyway because 
that do nothing.

For the most part, all methods accessible in Ruby when you start up are 
pretty generic, betraying no implementation details. There are some 
exceptions, like Continuations, but even there it's not something that 
can't be supported on an impl like JRuby, it just can't be supported 
efficiently.

There are methods in extensions that work on some impls/platforms and 
not on others, like most of the methods in 'etc' (nil on Windows), 
UNIXSocket (not available on Windows, again), win32api, and so on. In 
fact almost all features that will vary across platforms and impls are 
part of stdlib, usually as an extension.

And I think there's a fail-fast aspect to this too. If someone builds an 
app to run on MRI and once a day call one of your GC methods, they 
wouldn't see that the method doesn't exist in JRuby until they had it 
running for a day. If they were required to load a library to get that 
method, they'd see it immediately and not use it or find another way.

It's pretty painless to put those methods in an extension. I guess I'm 
an advocate of keeping the core set of Ruby methods as lean and 
impl-detail-free as possible...for obvious reasons :)

- Charlie