Timothy, I've been thinking about this a bit more and I see that you can supply data via a function in a function map that is part of extend. And while self reference between the various parts of a composite can get awkward, you can always revert to a function to complete that self-reference the same way I do with my core functions which have no knowledge of the implementations involved, except that you may be forced to do reflection.
I think the approach I am proposing is simpler both in that it avoids some of the boiler plate (thought I'd never say that about Clojure!) and completely bypasses the need for reflection. Within a composite (where opts is the name of the composed map) you can easily call any "method" like this: ((:some-method opts) arg1 arg2) without worrying about the order in which things are defined--one of the big weaknesses of Clojure compared to Java. Of course, now there is even less type checking that even the little that Clojure normally provides. But again, you can always define simple functions so that you don't end up invoking closures all over the place via (:method-key opts). In any case, I'm having fun. And while the approach is not the fastest, I seem to be producing rock-solid stable code. Which for me is a great big plus! -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
