Project

General

Profile

Actions

Feature #7704

open

Add a list of enabled (experimental) language features.

Added by mpapis (Michal Papis) about 11 years ago. Updated about 6 years ago.

Status:
Open
Target version:
-
[ruby-core:51459]

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.

Updated by naruse (Yui NARUSE) about 11 years 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).

Updated by phluid61 (Matthew Kerwin) about 11 years 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 :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.

Updated by drbrain (Eric Hodel) about 11 years ago

  • Target version set to 2.6

Updated by ko1 (Koichi Sasada) about 11 years ago

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

Updated by duerst (Martin Dürst) about 11 years 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.

Actions #6

Updated by naruse (Yui NARUSE) about 6 years ago

  • Target version deleted (2.6)
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0