From: Albert Wagner <alwagner@...>
Date: 2000-05-12T12:35:14-05:00
Subject: [ruby-talk:02796] Re: Array.pop and documentation [was:Append alias  for Array.append?]

I hope it's OK for a newbie to comment here.  Why complicate things with
three signatures? Why not just:
    slice(n,m)
where n=pos & m=length
so that:
    slice(0,1)     # slice_low        1st
    slice(0,3)     # slice_low(3)     1st 3
    slice(-1,1)    # slice_high       last
    slice(-3,3)    # slice_high(3)    last 3

schneik@us.ibm.com wrote:
> 
> Hi,
> 
> Aleksi writes:
> 
> # Conrad,
> # >    slice_low
> # >    slice_low(n)
> # >    slice_high
> # >    slice_high(n)
> # >    slice(n,m)
> # >where low and high refer to the end of the array with lowest and highest
> # >array index,
> #
> # I don't know about 'low' and 'high' (maybe start and end, or bottom and
> top
> # or,...) but the idea sounds ok.
> 
> I think horizontal/vertical-orientation-independent names would be best, so
> I like your recommendation of "start" and "end" best for slice/splice
> method names, especially since "start" and "end" still  have a pretty
> obvious semi-intuitive association with low and high
> array/list/stack/vector indices.
> 
> # >it would still have to wait for Ruby 3000
> #
> # Why?
> 
> The main reason was the preference to have everyone writing the same
> language, as it were. However, where there is an improvement in overall
> clarity, uniformity, simplicity, ease of remembering, and so on (as is
> hopefully the case here) versus merely adding otherwise redundant aliases
> to cater to Python/Perl/Whatever converts, then it may be better to make
> the addition now after all. I was also thinking in terms of method name
> replacement, not in terms of method name addition--but now that I think
> about it, addition now is probably preferable to waiting (perhaps forever)
> for replacement later.
> 
> # First, I think we can implement (at least for these) 'include Ruby3000'.
> 
> Very interesting idea. I like it.
> 
> # And then I think we can just divide the proposed version number by about
> # 1764.7055 and target these changes to 1.7 and stable release 1.8. Before
> # that we could note at the release at 1.6 that all these things (and many
> # more) might change in the future.
> 
> Ah, yes, of course. Why didn't I think of that? I had only thought of
> 1764.7049, which didn't quite work. :-)
> 
> # The people who want to stick with the old code, not change a line, can do
> # so. They just stick with the old interpreters too. If they want to
> # incorporate the patches from newer versions, they're able to do that
> through
> # - oh, what a beautiful world this is - Open Source.
> 
> OK, seems reasonable enough to me.
> 
> Conrad Schneiker
> (This note is unofficial and subject to improvement without notice.)

-- 
Small is Beautiful