Re: Set#map! vs. map

Hi --

On Tue, 3 Jun 2008, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Set#map! vs. map"
>    on Tue, 3 Jun 2008 17:33:02 +0900, "David A. Black" <[e-mail]> writes:
>
> |> Do you want to make a new rule that map should return the object of
> |> the same class as the receiver?  If so, what do you think collect
> |> (currently map's alias) should return?
> |
> |I wasn't thinking of a general rule, just wondering about the case of
> |Set.
>
> So, with making a general rule in your mind, what do you think?

I don't think map and collect should become different from each other;
it would be too hard to remember which is which. Also, I don't think
map could always return an object of the same class -- for example,
it wouldn't make sense with Range or IO.

What got me thinking about the possibility of a Set#map method,
returning a set, was just the fact that Set#map! exists at all (and
that it's the only map! other than Array#map!). That suggests that
sets are the only class, other than array, where a mapping back to the
class is considered possible, and that in turn made me wonder whether
a set was considered close enough to an array, in its interface, to
satisfy the requirements Ara was talking about (the polymorphic API).

So... I guess the general rule should either be that map always
returns an array, or that there's some minimum API that has to be
satisfied by the original class in order for it to work as the return
value of a mapping. That might be more trouble than it's worth,
though. Or maybe a new method, like map_back or something, to be
implemented by enumerable classes that *can* map back to their own
class.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   INTRO TO RAILS         June 9-12            Berlin
   ADVANCING WITH RAILS   June 16-19           Berlin
See http://www.rubypal.com for details and updates!