On Feb 6, 7:27 am, David Nolen <dnolen.li...@gmail.com> wrote:
> > Yuck. Instead of defining a method on ::idea, you now must define a
> > method on [something-that-has-no-meaning-in-context ::idea] (because
> > the dispatch function must now return a vector, which means the
> > defmethods must now be called on vector dispatch values...).
>
> Sure but as you mention below this could be hidden via a macro
> (defprotocol-method ...).
True, but also yuck (just because the more macros I add to support a
susbsytem, the less comfortable a get, in general; still, it may be
the way to go).
> This also could be used to implement something
> that works like eql specializers...
>
> > I was kind of sliding in another direction: I could always implement
> > CLOS-style method computation and sorting. But of course that might
> > mean not reusing multifn and its dispatch mechanism, and that seems a
> > shame. Maybe I could bury the defmethod ugliness in syntactic sugar...
>
> Looking at the requirements above it seems like you have something specific
> in mind for this system so perhaps Spinoza is not well suited for the
> particular thing you are shooting for. However all of your ideas are quite
> fantastic.
>
> I will definitely add protocol support to Spinoza, but it will probably be
> something that emphasizes static definitions with good support for runtime
> modifications. Your system sounds very interesting and it would be great to
> hear how it develops if only to get more ideas for Spinoza ;)
I built 4 iterations of a model/protocol/thing system, accumulating
more requirements for it with each iteration. This discussion has had
the nice side-effect of grooming my requirements into a tidy state
that I can use for reference. What I'm doing next is stripping out all
of the m/p/t stuff and implementing the application in question
without any of it, to see which of the requirements are really
requirements.
On the subject of Spinoza, when I read through the source, it reads
like a recapitulation of parts of tinyclos. tinyclos has the virtue of
presenting a reasonably complete metaobject protocol that can be used
to implement arbitrary OOP features. Maybe you don't want everything
in tinyclos, and maybe you don't want to do things in Spinoza the same
way that tinyclos does them, but if implementing a CLOS-like object
system, it still seems useful to compare the implementation to
tinyclos, if nothing else, to clarify the differences between what it
does and what is natural or convenient in Clojure.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
