Feature #7704: Add a list of enabled (experimental) language features.

• Status: Assigned
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[mpapis (Michal Papis)]

With multiple Ruby implementations and "experimental" features like "refinements" it would be nice to have an array or hash including list of enabled language features so developers could check it instead of auto-discovering code with some hacks.

Additionally a new keyword like require_features :refinements, ... could be introduced to allow easy validation via either exception or return status.

[naruse (Yui NARUSE)]

mpapis (Michal Papis) wrote:

With multiple Ruby implementations and "experimental" features like "refinements" it would be nice to have an array or hash including list of enabled language features so developers could check it instead of auto-discovering code with some hacks.

Such feature list system is used on many languages/platforms like W3C DOM.
As far as my understand such experiment are failed because such feature list is too rough to use.
Features are not all or nothing in real world, and they often have bugs.
So auto discovery won't work.

Additionally a new keyword like require_features :refinements, ... could be introduced to allow easy validation via either exception or return status.

Use defined?(define_method) or defined?(using).

[phluid61 (Matthew Kerwin)]

naruse (Yui NARUSE) wrote:

mpapis (Michal Papis) wrote:

With multiple Ruby implementations and "experimental" features like "refinements" it would be nice to have an array or hash including list of enabled language features so developers could check it instead of auto-discovering code with some hacks.

Such feature list system is used on many languages/platforms like W3C DOM.
As far as my understand such experiment are failed because such feature list is too rough to use.
Features are not all or nothing in real world, and they often have bugs.
So auto discovery won't work.

Not offering an opinion as such, just adding to the discussion.

I have in mind a related system: the OpenGL Extension Library. The registry of official language extensions is managed by an Architecture Review Board, and any OpenGL program can query the framework to detect the presence of an extension.

If Ruby were to support a similar system someone would be responsible for maintaining a registry of language features, including an explicit spec describing each feature (to which an implementation must fully adhere if it says it supports it). For example, the current "refinements" feature could be bundled under the name :REFINEMENTS_2_0 and match the current spec exactly; where a future version (e.g. :REFINEMENTS_2_1) would have a different spec.

That way a particular implementation may choose to implement some 2.0 features (e.g. kwargs) without others (e.g. refinements).

However, I imagine this would quickly become an unwieldy list, as per the OpenGL Extensions.

[drbrain (Eric Hodel)]

• Target version set to 2.6

[ko1 (Koichi Sasada)]

• Category set to core
• Assignee set to matz (Yukihiro Matsumoto)

[duerst (Martin Dürst)]

I can only second Yui and Matthew. Directly checking is possible because Ruby is a dynamic language, it avoids management overhead, and tests on the actual feature, not some intention that may be out of sync with actual facts. There are many organizations that have tried to do this, and most if not all have failed; I don't see any reason why we can't learn from them and use our time for more productive work on other stuff.

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned