Ruby Draft Specification | Hacker News Reader

Ruby Draft Specification

ruby-std.netlab.jp

23 pointsjudofyr6 comments

It would be great if our community of Ruby hackers could read this spec and supply feedback via their comment system. Remember that classes and methods that aren't included may not be present across implementations.

A few omissions that jumped out just from my quick scan:

- String.index & String.rindex - String.strip - Array.compact - Array.pack/String.unpack - Array.index & Array.rindex - Array.uniq - Enumerable.sort_by - Dir - Marshal

Would you be interested in a language that lacked these classes?

This to me is great news...a first step towards a "standard" ruby. With the various implementations running around out there, having a documented specification to refer to (and the ruby equivalent of the Java TCK, which I believe rubyspec is attempting to become) will be immensely helpful and will help further the language.

Yes, but their use of 1.8.7 as the baseline is an epic failure in my eyes. If we're moving to 1.9, use that. If you really must use a 1.8 series, don't use the weird-o transitional one that no one uses. That just doesn't make sense.

I also think they should work with the RubySpec (http://rubyspec.org) folks to make sure the executable spec is in sync with the written one.

But the Ruby core unfortunately isn't known for really reaching out across the Pacific, mostly because of the language barrier. :-/

Yes, very good point and a detail I missed. That's extremely unfortunate...the first spec of the language will lag far behind the version everyone should be using, and based on a transitional version that was controversial at best.

FTA:

Some might argue that we should use Ruby 1.9 as the primary reference, but Ruby 1.9 is moving fast and its features change frequently. Once we draft the specification based on Ruby 1.9, the specification and Ruby 1.9 would get quickly out of sync.

Well that's going to happen no matter what. It seems to be a lot of wasted and duplicate effort to base it on a soon-to-be-obsolete incarnation of the language. Build it piece by piece, starting with things that are definitely settled, then update as needed.

Reply on news.ycombinator.com