Ruby Draft Specification

Bjorn De Meyer wrote:

I made this issue as a meta-issue to group and discuss which methods and classes should or should not be included.

Thanks for your making this issue in good time.

This issue groups and is related to the following issues by Adam Doppelt:

#73 #72 #71 #70 #69 #68 #67 #66 #65 #64

I added them to the "related issues" of this issue.

My personal point of view is that we should limit classes and methods to whatever could be implemented in pure ANSI (ISO 1989) C without platform-specific extensions. Furthermore, if a method can be implemented easily in terms of other methods included in the standard, it may be omitted. But if it is impossible, difficult or a hassle to implement in terms of other methods included in the standard, it should be added.

It sounds good for me.

However, it's hard to concretely judge what should be included into the specification and what shouldn't be.
We therefore would like to get opinions as many as possible.

However, it's hard to concretely judge what should be included into the specification and what shouldn't be. We therefore would like to get opinions as many as possible.

I agree there. I also hope more people will comment here.

As for the methods mentioned in the related comments, I think as follows:

1. We don't need Dir, because there's no way to implement it in ANSI C
2. We don't need more methods on File, because there's no way to implement them in ANSI C
3. Enumerable#sort_by, is nice, but it can be implemented relatively easily in Ruby using Enumerable#sort and some helpers, so we don't need it.
4. Array#uniq may be implemented easily using Enumerable#sort and Enumerable#inject. We don't need #uniq.
5. Array#index and Arrray#rindex can aslo be implemented easily with a for loop or such. But they may be nice to have for consistency with String.
6. Array#pack and String#unpack have several formats that are platform-dependent, so it makes sense to omit both of them.
7. I don't think we need Array#delete directly, but more on that below.
8. Array#compact can be easily implemented, for example using Eumerable#inject. So we don't need #compact.
9. String#strip can be implemented using gsub, so, we don't need it.
10. String#index and String#rindex are not so easy to implement in terms of regular expressions. I'd like to include them in the standard as I stated before.

I suddenly realised that one other thing is missing in Array, IMO, and that's Array#delete_at. It is difficult to implement otherwise, since it works on the Array itself. Array is mutable in this draft standard. We have Array#shift and Array#pop, so Array can be used as a queue or as a stack. But it seems strange to me that we can delete elements from an Array at the beginning and at the end, but not in the middle! Arguably, if we have Array#delete_at, then it simplifies the definition of Array#shift and Array#pop, since they can be implemented easily for an Array a as a.delete_at(0) and a.delete_at(a.size-1) respectively. And Array#delete can also then be implemented easily using Array#delete_at.

To resume my point of view I think we would only need to add Array#delete_at, String#index and String#rindex, and maybe Array#index and Array#rindex for consistency reasons.

That's about it for my opinion on these. I'll think later if I can see something else I think to be missing.

To resume my point of view I think we would only need to add Array#delete_at, String#index and String#rindex, and maybe Array#index and Array#rindex for consistency reasons.

We will add these methods into the draft specification. Thank you.

OK, thanks! :)