On Feb 5, 3:01 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> > I don't argue that this model is better than what you're doing with
> > Spinoza, but for years (see
> >http://www.mactech.com/articles/frameworks/8_2/Protocol_Evins.html
> > from 1994) I've wanted an object model that explicitly separates
> > structure from protocol, and since I partially built one in order to
> > satisfy a need I had in a larger project, I think I'll push ahead with
> > it a bit to see whether it's worthwhile.
>
> Yes this is a good thing, but you get this behavior for free with Clojure's
> multimethods.

Not quite. Your points are well-taken, but don't describe what I'm
doing.

I'm not looking for a way to statically define protocols in which
classes participate. Consider an example similar to the one I gave in
my reply to Laurent:

(make-thing {:models [::vehicle ::airborne]
                   :protocols [::thing ::idea]
                   :inits {:name "test-thing1" :number 1}})

make-thing returns an instance whose fields are a combination of those
defined for ::vehicle and ::airborne, and which participates in the
protocols ::thing and ::idea (that is, methods that speciaize
on ::thing or on ::idea will operate on this thing).

Note that no classes are involved. The thing in question is not an
instance of any class (except incidentallly, by virtue of the fact
that Clojure's runtime is built on the JVM). I never defined any
classes, nor did I wish to. A class definition would have been just an
obstacle, not directly relevant to my goal, which was to instantiate
an object that reflects these models and participates in these
protocols.

Without further discussion, I don't know whether our goal are at cross
purposes; if not, maybe we can work out a congenial collaboration.
Note that I have not objection to classes in principle (and I'm a
longtime fan of CLOS), but I have no need of classes, and don't wish
to be compelled to use them.

My models are analogous to CLOS classes, except that there is no
inheritance involved, only accretion. In that respect, models resemble
objects in T more than in CLOS. My protocols are roughly analogous to
Haskell's typeclasses.

A proper collaboration would not result in CLOS for Clojure; it might
result in a type-definition and -extension facility that resembles
CLOS classes, but with a facility for specifying sets of multimethods
that looks a little more like Haskell typeclasses.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to