From: Alex Young <alex@...>
Date: 2008-04-05T03:04:13+09:00
Subject: Re: RUBY_IMPLEMENTATION

On Sat, 2008-04-05 at 02:23 +0900, Luis Lavena wrote:
> On Fri, Apr 4, 2008 at 2:15 PM, Chris Cummer <chris@postal-code.com> wrote:
> > On 4-Apr-08, at 3:05 AM, Eleanor McHugh wrote:
> >
> >
> > > Well RUNTIME makes more sense to me than ENGINE, but it still suggests
> > that code should be written to suit a particular runtime when what coders
> > really want to know is what FEATURES are available on the platform.
> > >
> > > I therefore favour a constant RUBY_FEATURES
> > >
> >
> >  This is the first time I've seen this particular suggestion put forth and
> > at the risk of being heretical, what about both?
> >
> >  I see merit in Alex's use-case (though I'm not fond of the over-loading of
> > "require"; perhaps feature_exists?() instead?):
I don't think it's overloading at all; load() exists to load code,
require() exists to signal that a particular feature is, well, required,
and do whatever is necessary to provide it or break in the attempt.
This idiom is already quite common:

begin
  require 'rubygems'
  require 'foo_gem'
rescue LoadError
  require 'foo_local'
end

My suggestion is just an extension of that.

> > > begin
> > >  feature_exists?( Features.threading.native )
> > >
> > >  setup_code_for_native_threads()
> > >  FeatureSet::Threading::Native # => true
> > > rescue LoadError
> > >  feature_exists?( Features.threading.green ) # or let this be a default
> > >
> > >  setup_code_for_green_threads()
> > >  FeatureSet::Threading::Green # => true
> > >  FeatureSet::Threading::Native # => false
> > > end
> > >
> >
> >  yet at the same time it feels right to be able to "know" as much as
> > possible about the actual environment in which the code is running. Of all
> > the proposed suggestions I find RUNTIME to be the most palatable.
> >
> 
> 
> Mmm, why don't use the current available keywords?
> 
> if defined? FeatureSet::Threading::Native
>   # ...
> else
>   # ...
> end
> 
By using require(), we open the door to being able to select
implementations in runtimes that are capable of supporting more than one
implementation of a given feature.  defined? can't do that without
metatrickery, which I would personally think of as too much magic.
Also, I think it reads better, but that's just my aesthetic opinion.

-- 
Alex