Hi --

On Fri, 22 Jun 2007, Rick DeNatale wrote:

> On 6/21/07, dblack / wobblini.net <dblack / wobblini.net> wrote:
>>
>> I like having arrays be the "common currency" of select operations.  I
>> don't think there's anything that you're prevented from doing as long
>> as that's the case.
>
> I know you do, it's consistent with the positions you took back when
> we were discussing to_splat. But I think that the case can be made
> that preserving the class of these methods is MORE not less
> duck-typed.

Maybe, but I'll admit that at this stage in this thread, I'm more into
the concrete question of what harm is done by having array be the
common currency.  (I'm having trouble following the duck-typing stuff
beyond a certain level of abstraction.)  I guess it's just never
bothered me, which is probably an excessively home-spun way to put it
but it's about the most rigorous analysis I seem to be up to right now
:-)

There's another thing, though, and that is the question of the
symmetry.  I'm trying to put my figure on why it doesn't bother me
that Hash#reject returns a hash and Hash#select returns an array --
that is, I don't like the fact that Hash#reject is different from
other rejects (at least I somewhat don't), but in and of itself I
think the fact that reject is not simply defined as !select doesn't
bother me.

Maybe it's something like: rejecting means subtracting from a thing
that's already there, but selecting means creating a new collection --
which of course doesn't preclude having that collection be a hash, but
does mean that there's a threshold of deciding what the new collection
will, or could, be.

It would interesting if:

   "abc\ndef\nghi".reject {|s| /abc/.match(s) }

resulted in "def\nghi"....


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)