Re: map.el and naming

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 2 Mar 2015 14:33:14 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Nicolas Petton <nicolas@petton.fr>, emacs-devel <emacs-devel@gnu.org>
> 
> > But polymorphism _is_ about using the same APIs for treating different
> > objects.
> 
> Yes, but associations (or maps) and sequences are not just different
> objects, they're different abstractions too. There are many operations
> which make sense on both, but even then Emacs has no automatic way of
> deciding which version to employ (see below).

I thought the object type should give enough information about that.

> Now, take a plist as an example. If you call `seq-map' on a 2-element
> list where the first element happens to be a keyword, `seq.el' has no
> way of knowing if you intended to use that as a sequence or as an
> association, therefore it just can't handle both cases.
> That's why you need two libraries. If you want to map over sequences,
> you call seq-map, if you want to map over an association, you call
> `map-map' (or whatever it ends up being called).

I asked whether it would make sense to have the same APIs for both
groups, and where just the type of the object provides enough
information for choosing how to process it.  If you are saying that
doesn't make a lot of sense, then I guess polymorphism doesn't make
much sense in this case.

> This won't only happen with mapping, I think it will happen with
> enough other functions to warrant a different library. Of course this
> library doesn't have to reimplement everything from scratch, it can
> and should fallback on seq.el whenever possible (just like seq.el
> sometimes falls back on built-ins like `mapcar').

If there are APIs that make sense for maps, IMO they should be generic
APIs that can handle both objects now handled by seq.el and those in
map.el.  IOW, if only some of the APIs must be map-specific, that
doesn't mean we need to make them all map-specific, IMO.