From: Brent Roman <brent@...>
Date: 2009-02-16T04:38:43+09:00
Subject: [ruby-core:22156] Re: A short memorandum (Re: 1.8.7 Specifics)


Charlie,

As usual, there is no one "right" answer. 

The GC module *is* Ruby's API to its "automatic memory management".
Even a ref-counted implementation would have some user tweaks.
And, if it didn't, the ref-counting GC would simply define a GC module with
no methods.
Easy.

We are not talking about core API methods that will see use throughout many
applications.
This is very much on the fringe. 

Further, fail fast is simply not something that Ruby does well.  It's a
trade off for its
dynamic nature.  Whether or not all GC methods exist as stubs or not won't
make much difference.
It's the nature of the beast.

Having the set of GC methods exist conditionally has two concrete
advantages:
 1)  implementers don't have to jump through hoops trying to emulate
behaviors that are not relevant to their GC implementations.

 2)  application writers can tailor their code to interact optimally with
*any* GC by querying its methods to see what contracts it supports and
adjusting their behavior appropriately.  If they must first require a
'specificGC' extension, their code will fail if specificGC is not available. 
So, then they start probing for all the specificGC's they know...

I'm also an advocate of keeping the core lean, but this integral to the core
and tiny relative
to things like Array#sample and non-Latin languages.

In any case, a compromise is certainly possible.  GC could be required to
implement the
current small set of methods.  Any additional ones would be optional and
standardized across
implementations.

- brent


-- 
View this message in context: http://www.nabble.com/-ruby-core%3A21997--1.8.7-Specifics-tp21961585p22026480.html
Sent from the ruby-core mailing list archive at Nabble.com.