Feature #7704

Add a list of enabled (experimental) language features.

Added by Michal Papis over 1 year ago. Updated about 1 year ago.

[ruby-core:51459]
Status:Open
Priority:Normal
Assignee:Yukihiro Matsumoto
Category:core
Target version:next minor

Description

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.

History

#1 Updated by Yui NARUSE over 1 year ago

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

#2 Updated by Matthew Kerwin over 1 year ago

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 :REFINEMENTS20 and match the current spec exactly; where a future version (e.g. :REFINEMENTS21) 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.

#3 Updated by Eric Hodel about 1 year ago

  • Target version set to next minor

#4 Updated by Koichi Sasada about 1 year ago

  • Category set to core
  • Assignee set to Yukihiro Matsumoto

#5 Updated by Martin Dürst about 1 year ago

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.

Also available in: Atom PDF