On Wed, Jan 4, 2012 at 3:05 AM, Tassilo Horn <tass...@member.fsf.org> wrote:
> There's no logic in there. It's just the only place where users like me
> are able to return some predicate for the dispatch instead of a
> non-function value.
>
It's not true that that's the only place you can put information -
core.match is extensible. But putting that kind of information there
doesn't make much sense (at least to me). IMatchLookup is only for pattern
matching on maps.
> > I'm not sure about the following syntax, but something like this could
> > be done w/o interfering with IMatchLookup.
> >
> > (match [obj]
> > [({:mice 4} :type cat)] ...
> > [({:cats 4} :type dog)] ...
> > [({:cats 4} :type :not [cat dog]] ...)
> >
> > This can be done by creating something like TypePattern which would
> > understand these various cases.
>
> And cat and dog would be some Java classes, interfaces, protocols,
> types, records, right?
No they can be whatever you want.
The warning sign here is that you have to be invasive and change the way
that literal and map patterns work in order to get the behavior you want.
core.match was designed to avoid that kind of thing as much as possible.
There may of course be places where modular extensibility doesn't work out
- but these areas should be identified and fixed.
David
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
