Select and select

ruby-talk
21

Hi,

Would it be less confusing to extend the behavior of #entries, instead,
like this:

[0,1,2,3,4].entries(1,3) #==> [1,3]

or would this lead to the same problems as with overloading #select?

To avoid repeating same disuccsion again, let me summarize:

We want to have a new method to replace “indices”, because of
inconsistency between “indices” (or “indexes”) and “index”. “index”
returns index of a value, “indices” returns values corresponding to
indices.

A new method (say “quux” for example) should satisfy

  • obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
    collections (i.e. Array, Hash, MatchData and Struct), perhaps
    except for String, which is mere string of characters rather than
    indexable collection. So preferably it should sound natural both
    for arrays, hashes and others.

  • obj.quux() either returns an empty array or causes exception, due
    to the case like obj.quux(*ary) where ary is an empty array.

    					matz.
···

In message “Re: select and select” on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

22

What about just a[x,y,z]?

Massimiliano

···

On Fri, Sep 20, 2002 at 02:33:43AM +0900, dblack@candle.superlink.net wrote:

For Arrays I do like at(x,y,z).

23

Yukihiro Matsumoto wrote:
…

We want to have a new method to replace “indices”, because of
inconsistency between “indices” (or “indexes”) and “index”. “index”
returns index of a value, “indices” returns values corresponding to
indices.

A new method (say “quux” for example) should satisfy

  • obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
    collections (i.e. Array, Hash, MatchData and Struct), perhaps
    except for String, which is mere string of characters rather than
    indexable collection. So preferably it should sound natural both
    for arrays, hashes and others.

  • obj.quux() either returns an empty array or causes exception, due
    to the case like obj.quux(*ary) where ary is an empty array.

I have to agree, that’s the right behavior. So we will have

[0,1,2,3,4].entries #==> [0,1,2,3,4]
[0,1,2,3,4].quux #==> (or an exception)

So far, so good. But what should the name be? Both “items” and
“elements” seem too close to entries in their natural language meaning.
There were good arguments against using “at” (doesn’t seem to fit
hashes, reduces efficiency of Array#at).

Does “indexable collection” mean anything that responds to # ?

If so, then proc and method objects come into play, and the perfect name
would make sense for them as well. But in this case the quux method
would be just another way of writing #map, so maybe this isn’t important
to consider after all.

What about these?

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I guess I still like select best.

24

The latter makes that other proposal inappropriate,
I see now.

Hal

···

----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, September 19, 2002 7:14 PM
Subject: Re: select and select

A new method (say “quux” for example) should satisfy

  • obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
    collections (i.e. Array, Hash, MatchData and Struct), perhaps
    except for String, which is mere string of characters rather than
    indexable collection. So preferably it should sound natural both
    for arrays, hashes and others.

  • obj.quux() either returns an empty array or causes exception, due
    to the case like obj.quux(*ary) where ary is an empty array.

25

Then you’d have a special case when just one element is returned:

a[x,y,z] => [a, a[y], a[z]]
a[x,y] => [a, a[y]]
a => a

Paul

···

On Sat, Sep 21, 2002 at 12:47:13AM +0900, Massimiliano Mirra wrote:

On Fri, Sep 20, 2002 at 02:33:43AM +0900, dblack@candle.superlink.net wrote:

For Arrays I do like at(x,y,z).

What about just a[x,y,z]?

26

What about just a[x,y,z]?

a[x,y] is already defined

pigeon% ruby -e 'p [1,2,3,4][1,3]'
[2, 3, 4]
pigeon%

Guy Decoux

27

A new method (say “quux” for example) should satisfy

Would it be possible to change Array#fetch and Hash#fetch
to take more than one argument?

%w[a b c d].fetch(1,2)
==>[“b”, “c”]

{“a”=>0,“b”=>1,“c”=>2,“d”=>3}.fetch(“b”,“c”)
==>[1, 2]

Using a block would be nice and short, too:

%w[a b c d].fetch(1,2) { |x| p x }
“b”
“c”
==>[“b”, “c”]

  • obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
    collections (i.e. Array, Hash, MatchData and Struct),

I think that point is very important. I would prefer to be able to
exchange data structures in my code without changing every access to
them. Changing the hash/array and reference/direct stuff all the time is
one thing I hate most about Perl.

···

Am 2002-09-20 09:14:10 +0900 schrieb Yukihiro Matsumoto:

–
Never attribute to malice that which is adequately explained by stupidity.
– “Hanlons Razor”

28

matz@ruby-lang.org (Yukihiro Matsumoto) wrote in message news:1032480831.688890.8657.nullmailer@picachu.netlab.jp…

We want to have a new method to replace “indices”, because of
inconsistency between “indices” (or “indexes”) and “index”. “index”
returns index of a value, “indices” returns values corresponding to
indices.

Has anyone suggested ‘values’? array.values(1,2,3) sounds reasonably
natural, as does hash.values(key1, key2, key3).

martin

29

Can I put another?

 retrieve     (long?)
 list         (unclear?)

list sounds not bad for me (at the moment).

– Gotoken

···

At Fri, 20 Sep 2002 12:04:34 +0900, Joel VanderWerf wrote:

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I guess I still like select best.

30

Hi,

···

In message “Re: select and select” on 02/09/21, Florian Frank flori@nixe.ping.de writes:

Would it be possible to change Array#fetch and Hash#fetch
to take more than one argument?

Hash#fetch already has optional second argument. Besides,

a.fetch(idx,idx2)# => [value, value2]

is not really a natural extension of

a.fetch(idx) # => value

Probably, a.quux(i) should return an array.

						matz.
31

Hi,

···

In message “Re: select and select” on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

What about these?

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I like “pick”. How do others feel (especially English speaking ones)?

						matz.
32

In article 3D8A90F4.8080400@path.berkeley.edu,

Yukihiro Matsumoto wrote:
…

We want to have a new method to replace “indices”, because of
inconsistency between “indices” (or “indexes”) and “index”. “index”
returns index of a value, “indices” returns values corresponding to
indices.

A new method (say “quux” for example) should satisfy

  • obj.quux(a,b,c) returns [obj[a],obj[b],obj[c]] for all indexable
    collections (i.e. Array, Hash, MatchData and Struct), perhaps
    except for String, which is mere string of characters rather than
    indexable collection. So preferably it should sound natural both
    for arrays, hashes and others.

  • obj.quux() either returns an empty array or causes exception, due
    to the case like obj.quux(*ary) where ary is an empty array.

I have to agree, that’s the right behavior. So we will have

[0,1,2,3,4].entries #==> [0,1,2,3,4]
[0,1,2,3,4].quux #==> (or an exception)

So far, so good. But what should the name be? Both “items” and
“elements” seem too close to entries in their natural language meaning.
There were good arguments against using “at” (doesn’t seem to fit
hashes, reduces efficiency of Array#at).

Does “indexable collection” mean anything that responds to # ?

If so, then proc and method objects come into play, and the perfect name
would make sense for them as well. But in this case the quux method
would be just another way of writing #map, so maybe this isn’t important
to consider after all.

    • How about “axiom_of_choice[1]” ? That’s really what you’re
      implementing. You could use “zermelo” or “zerm” for
      short. Nobody but a mathematical logican will have any prior
      meaning attached to that. Just think of the possiblities:

    “Yeah, I need to zerm the Hash”

    “Hey is Mailbox class zermable ?”

    • Personally, I kind of like “choose”, but I think that’s
      already been rejected in this debate.
    • Booker C. Bense

[1] - Axiom of Choice

···

Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote:

33

See http://ruby-talk.org/50932

···

At Mon, 23 Sep 2002 21:33:05 +0900, Martin DeMello wrote:

Has anyone suggested ‘values’? array.values(1,2,3) sounds reasonably
natural, as does hash.values(key1, key2, key3).

34

Is there a general concensus as to the best tool/format for documenting Ruby
classes?

35

Hash#fetch already has optional second argument.

What a pity! I have overlooked that.

Probably, a.quux(i) should return an array.

Yes. It should also have a short method name. In this regard quux
wouldn’t be so bad. We could start such a fine tradition like Lisp’s
car/cdr here… :wink:

···

Am 2002-09-21 21:24:25 +0900 schrieb Yukihiro Matsumoto:

–
You can create art and beauty on a computer.
– Steven Levy, “Hackers: Heroes of the Computer Revolution”, 1984

36

Hi –

Hi,

What about these?

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I like “pick”. How do others feel (especially English speaking ones)?

Just so I can see it in action:

ar = %w{ one two three four }

ar.pick(0,3) # => [“one”, “four”]
ar.select {|e| e.size == 3} # => [“one”, “two”]
ar.pick() # => (or ArgumentError?)

h = {“one” => 1, “two” => 2}
h.pick(“one”, “two”) # => [1,2]

I agree with Joel that it’s close in meaning to select, but for some
reason it doesn’t bother me. I find it pretty clear, possibly a
little better suited to arrays than hashes but still OK.

Just to throw in something else, I was thinking about “find_at”,
which I like as a complement to #find_all:

ar.find_all { condition }
ar.find_at(1,3)

David

···

On Sat, 21 Sep 2002, Yukihiro Matsumoto wrote:

In message “Re: select and select” > on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

37

pick is short and too the point.

···

On Sat, 2002-09-21 at 08:25, Yukihiro Matsumoto wrote:

Hi,

In message “Re: select and select” > on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

What about these?

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I like “pick”. How do others feel (especially English speaking ones)?

  					matz.

–
tom sawyer, aka transami
transami@transami.net

38

Not a native speaker, but it’s short, clear and makes sence for both hashes
and arrays. It’s also a more human and less technical – if you take my
meaning. On the downside, nothing about it suggest that it return an array.

== Good, but not perfect :wink:

– Nikodemus

···

On Sat, 21 Sep 2002, Yukihiro Matsumoto wrote:

I like “pick”. How do others feel (especially English speaking ones)?

39

It’s OK, but I think not ideal…

If the motivation is the conceptual conflict between
“index” and “indices” (they’re named nisleadingly
similarly but do opposite things) then I think
I would do the reverse: Change “index” to “find_index”
(which is clearer anyway).

But there is probably some good reason not to do this.

Hal

···

----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Saturday, September 21, 2002 9:25 AM
Subject: Re: select and select

Hi,

In message “Re: select and select” > on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

What about these?

at_indices (too long, ugly)
sample (not very clear)
pick (too close to select)

I like “pick”. How do others feel (especially English speaking ones)?

40

It’s okay. But why not overload “values”?

Tom.

···

Hi,

In message “Re: select and select” > on 02/09/20, Joel VanderWerf vjoel@PATH.Berkeley.EDU writes:

What about these?

at_indices (too long, ugly)

sample (not very clear)

pick (too close to select)

I like “pick”. How do others feel (especially English speaking ones)?

–
.^. .-------------------------------------------------------.
/V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk |
/( )\ | Open Source/UNIX consultant | tom@linuxbrit.co.uk |
^^-^^ `-------------------------------------------------------’