From: ruby-ml Date: 2008-06-08T06:27:57+09:00 Subject: [ruby-core:17139] Re: Standardizing RUBY_PLATFORM RFC. Excerpting brixen, Thu Jun 05 00:12:24 -0400 2008: > On Jun 4, 8:52pm, Brian Ford wrote: > > > Charles Nutter suggested in the Ruby design meeting on June 4/5, that > > the value of RUBY_PLATFORM should reflect the layer just below Ruby > > code, which is really the implementation. That layer should be > > identified by RUBY_ENGINE instead. The value of RUBY_ENGINE has been > > agreed on but I don't believe it's been implemented anywhere outside > > of Rubinius. RUBY_ENGINE would be 'ruby' on MatzRuby, 'jruby' on > > JRuby, 'rbx' on Rubinius, and undefined as yet AFAIK on IronRuby, > > MacRuby, and MagLev. > > After more discussion, it would appear inescapable that we actually > need *three* standard values to distinguish this. One is > RUBY_PLATFORM, whose value needs to be defined. One is RUBY_ENGINE, > whose value has been defined. And the third is another constant that > would represent 'java', 'clr', etc. Essentially, the layer between the > OS+arch at the bottom, and the implementation at the top, just below > the Ruby code. > > We need a name for the new constant. We need to define it's contents. > And we need to define what RUBY_PLATFORM will mean. Revised proposal for the common constants =========================================== RUBY_ENGINE ------------- Single-word lowercased name of the implementation codebase. MatzRuby's is "ruby", the other engines will come up with their own name although this is usually just the project name. For example, Rubinius will have RUBY_ENGINE == "rubinius". RUBY_PLATFORM --------------- A string generally in the format currently used for RUBY_PLATFORM, with the exception that it may also contain the additional compatibility layer name like e.g. "java" or "java6" for JRuby, "clr" for IronRuby and so on. Each engine team can define the exact string and its location although it would probably be simplest to just prepend it. The information is accessible in the string, usually using a regexp: # MatzRuby RUBY_PLATFORM = "mips64-Plan9-edition4" # JRuby RUBY_PLATFORM = "java-mips64-Plan9-edition4" # Etc. I do not feel it is necessary for every engine to have the same number of components or use the same format in the platform string but if it is needed, something like "none" or "unknown" could be used as the default and then JRuby can substitute that with "java" and so on. This could be further enhanced by creating a specialised object to contain the platform information. The object would be usable transparently as a String in the above format, but platform info would actually be stored as discrete data so that users have easier access to the various components, e.g. RUBY_PLATFORM.cpu. RUBY_VERSION -------------- Version of the Ruby language implemented by the engine, as set by MatzRuby. A RUBY_VERSION of "1.8.6" means that any code that works on the 1.8.6 release from http://ruby-lang.org should work exactly the same on this engine. Same for any other version. Versioning has been a source of contention recently, mainly because _PATCHLEVELs have been used to actually make changes in functionality. In the future, they should be used strictly for bugfixes (and they should only ever be checked by users to see whether the bug has been fixed.) In the long term, Ruby versioning would benefit from adding a 4th component to the version string, e.g. "1.8.6.p114" instead of the patchlevel being a separate entity. This simplifies version checks. In the short term, regardless of decisions made for the above, the version should be made available as an Array of Fixnums rather than or in addition to the current String. For example, we could have a constant RUBY_VERSION_NUMBER == [1, 8, 7, 114]. The Array is trivial to compare against incomplete versions, e.g. when someone just wants to make sure they are dealing with an 1.8.x rather than a 1.6.x. It can be joined wherever the String version is needed. One alternative would be to use a specialised object here as well: the data could be transparently used either as an Array or the traditional String. #{RUBY_ENGINE.upcase}_VERSION ------------------------------- Freeform version identifier for the engine. For MatzRuby, the constant is the same, RUBY_VERSION, while RUBINIUS_VERSION could be "0.9.0-rc1" and other platforms are free to use "1.2," "some droll version name" or whatever happens to apply. The contents are engine-specific. Any other details beyond these will be accessible in some unspecified, engine-dependent way whether through RbConfig or some other means. It could be stored in RUBY_PLATFORM, for example, if it is promoted to a full-fledged object. Thoughts?