David Nolen <dnolen.li...@gmail.com> writes:
> Putting that kind of logic in IMatchLookup doesn't make much sense to
> me:
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.
> 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? (In my case, that probably wouldn't help too
much because the classes are generated and compiled at runtime, so I'd
need to say
[({:mice 4} :type (Class/forName "some.very.long.package.name.cat")] ...
which is even worse than putting a predicate in a guard.
> However it does sound like you want predicate dispatch.
That ring's a bell. I've seen your video some weeks ago, but forgotten
your notes on predicate dispatch and turned to what's there right now.
> Whatever syntax is decided upon needs to work for the open dispatch
> case as well as it does for the matching case.
>
> Predicate dispatch is on the roadmap but still some ways off.
> Definitely open to discussion.
Thanks for the hint.
Bye,
Tassilo
--
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
