On Mar 26, 8:59 am, Rich Hickey <richhic...@gmail.com> wrote:
> On Mar 25, 6:47 am, mikel <mev...@mac.com> wrote:
[...my misgivings snipped...]
> I wonder about the generality of this concern. Defining new methods
> that break existing code implies both defining new methods on existing
> super-types *and* some crosscutting multiple inheritance. I've seen it
> happen only when first building method sets on existing hierarchies
> not designed with this system in mind, e.g. when superimposing methods
> on Java hierarchies. If you have an existing hierarchy from CLOS and
> are disappointed that Clojure's multimethods don't work like CLOS,
> well, ok.
I don't have such a hierarchy. Rather, I have a domain-specified set
of data and a set of requirements for APIs. I know how to build a data
dictionary and API for these requirements in several languages; I
don't (yet) know how to do it in Clojure.
> However, all is not rosy with CLOS, and I've run into problems with
> the left-to-right semantics of both arglists and superclass lists many
> times, trying to game precedence lists etc. There's somethjing
> inherently broken with not being able to derive from two superclasses
> that have the same bases, just because they have different derivation
> orders - see bottom of:
>
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec...
I'll take your word for it that you've run into problems on this
point. I haven't.
The page that you cite explains what the potential conflicts are and
tells you what not to do, so that you can avoid those conflicts. Is
there an equally clear explanation of what not to do in Clojure, so as
to avoid visiting dispatch conflicts on users of my libraries? I
looked for such an explanation, but haven't found it yet. I hope I've
just missed it; I'd really rather use the built-in features of the
language.
> Plus the inability to dispatch on other than class or eql, the
> inability to superimpose another taxonomy without redefining the
> class, the inability to have multiple independent taxonomies...
At least two of the projects I've worked on using CLOS (Apple's
Bauhaus and SK8 projects) did all of those things. If you mean, those
things are not ready to go out-of-the-box in CLOS, you're right. All
the CLOS implementations I've worked with, however, provide good
support for implementing those sorts of alternatives if you want them.
That's no slight on Clojure; I've found that Clojure also provides the
tools I need to build alternatives to the built-in features.
> The reason Clojure doesn't have an elaborate system like CLOS, or even
> like Python et al is that all of those systems have limits and quirks
> and hardwiring one into a language is a bad idea, IMO. Clojure's
> hierarchies and multimethods are just libraries - there's no reason
> you couldn't define a CLOS-like object system for Clojure (although
> any such system will have problems integrating Java's type hierarchy
> because there is no definitive superclass ordering). I'm just trying
> to tease out the useful ingredients of OO and make them available a la
> carte.
I wholeheartedly endorse this approach. I just have this one problem
with MultiFns: as far as I can tell, they expose the internals of my
library implementations in unfortunate ways. Suppose you're using an
extensible codec API and you add support for a novel combination of
data formats. You write a new method and discover a brand new error
caused by a dispatch ambiguity. Now what? How do you find out what the
cause of the error is? What should the library provider have done to
ensure that you would not have this problem? What do you do to ensure
that your colleagues and customers won't have this problem?
The question isn't rhetorical; I actually encountered this exact
situation more than once, and it's the reason that I diverted time
from getting my main application done to writing a generic-function
library that makes that problem go away. The generic function library
works: the problem goes away, and all the relevant tests pass.
Go ahead and tell me that I failed to understand MultiFns correctly;
that would be good news. If you can tell me how to prevent the
aforementioned situation using MultiFns, then I can abandon generic
functions without regret, and get back to my actual goal. Note that I
am not asking for an estimate of how likely that sort of problem is.
Several people have mentioned that they don't think it very likely.
Their optimism aside, what interests me is a deterministic method of
preventing problems that have actually arisen.
> What I like about preference declarations is that you are
> acknowledging a definite ambiguity in a pure derivation hierarchy
> rather than poisoning the notion of hierarchy with directionality.
Why is it poison? The DAG will be traversed in some order; you're just
saying that you're not going to say what that order is. That's fine as
long as *I* can specify the traversal order, and I can, in part. But,
unless I've missed something important (always a possibility), prefer-
method only permits me to specify the order for graphs that are
already constructed. To make a safely-extensible library, I need to
specify the traversal order for subgraphs that are not yet
constructed. Again, if there's a good way to do that and I've missed
it, I'll orphan my generic-functions code in a heartbeat.
> That said, perhaps the preference specifications at the method level
> aren't as reusable/convenient as preferences declared at another level
> or somewhere else.
I think for my purposes it would be sufficient to have a way, when
creating a hierarchy, to say, "hey, we're gonna traverse this one in
this order, okay?"
> I do care about making this easier to use, but arguments from
> familiarity are insufficient
I wasn't planning to make one anyway, but thanks for the heads-up.
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
