ruby picture

RCR 288: Concat Block

Submitted by transami (Wed Dec 15 13:12:13 UTC 2004)

Abstract

There are times when a filter needs to be applied to elements being concat'd to an array. Having a simple way to accomplish via #concat itself would a nice convenience.

Problem

Simply a matter of convience and the fact that concat does not currently have any use for a block parameter --this is a useful possibility. So instead of:

  a.concat(b.collect {|e| ... })

one can simply write:

  a.concat(b) {|e| ... }

Proposal

Allow concat to take a block that filters each element being appended to the array.

Analysis

No major analysis. Just a simple non-obtrusive suggestion.

Implementation

In pure Ruby

  class Array
    alias oconcat, concat
    def concat(arr, &blk)
      if block_given?
        oconcat(arr.collect(&blk))
      else
        oconcat(arr)
      end
    end
  end
ruby picture
Comments Current voting
I'm not drawn to this. It's a bit to much of a special or particular usage case getting its own syntax, which is a never-ending road down which I prefer Ruby to go as little as possible. The syntactic building blocks are already awfully concise.

It's also not clear why collect gets to be the default here. One might also concat the results of a select or reject operation -- and then one would fall back on:

  a.concat(b.select {|e| e > 1}) # or whatever

To save typing 'collect' (or 'map' :-) by making a special default collect case where the block comes after the parens doesn't strike me as worthwhile. Also, consider that you'd still have to do:

  a.concat(b.collect! {|e| e *2 })

i.e., the bang case, explicitly. I'd rather not have one more special case to learn (and have to explain).


Whoops, I forgot to sign my comment: -- David Black


Hmm. I don't think the in place variation is signifficant, but I do see your point with #select --that is a viable alternative. But I disagree that it is a never-ending road down a special or particular usage case. It's just a choice between a few viable general usage cases.

There is a philosophical divide here. Do we "fill-up" the capabilities of methods where viable, or not? In other words, in this case, since concat doesn't have any current use for a block, isn't it better that it do something rather then nothing --even if we must pick one of a number of alternative functionings?

These issue are also not not an all or nothing choice. I just tend to _lean_ toward filler-up. Mostly b/c the alternative lead to many additional method definitions (and calls) --and Ruby is slow on method lookup.


I wish I could edit my comment :(. Oh well. -T.


I think it breaks modularization, assuming that concat is going to be used after filtering some items. I don't like that.
     Mariano Montone


Strongly opposed 5
Opposed 2
Neutral 1
In favor 0
Strongly advocate 0
ruby picture
If you have registered at RCRchive, you may now sign in below. If you have not registered, you may sign up for a username and password. Registering enables you to submit new RCRs, and vote and leave comments on existing RCRs.
Your username:
Your password:

ruby picture

Powered by .