> > 1) User-friendly printing. > > I implement the multimethods print-method and print-dup for my > classes, which allows me to specify how objects are printed. print- > method and print-dup dispatch on class, so my types need to be > classes or at least derive from a class that is distinct from the > standard Clojure data structures.
Should print and println be multimethods? It seems the ability to custom print a data structure would be generally useful. > > 2) Usability in multimethods > > The above argument illustrates a more general problem: multimethods > meant for use with a wide range of data structures can in practice > only use class as a selector, as that is the only one that will work > for the built-in data structures. Look at fmap in > clojure.contrib.types.examples, for instance. It would make sense to > add an implementation for maps that applys f to the value of each map > entry. But I can't have that plus a type system based on maps with > special tags - it's one or the other. Not totally following here, looking at your code... Pardon my slowness but why not dispatch on :tag first, and class if no :tag? > > 4) Modularity > > There are bound to be several type or class systems for Clojure, as > for other Lisps. We already have Spinoza, for example. If all these > systems use maps with type tags, there are bound to be tag conflicts > sooner or later. For example, someone will create a Spinoza class > with a slot whose name interferes with my special type tag. This > can't happen with my closure-based implementation. It creates objects > that are distinct by the very nature of their classes, so it doesn't > interfere with whatever someone else may come up with. > Tags of course should be namespaced so is this really that much of an issue in practice? Since tags are keywords they don't have the interning conflict problem that symbols of the same name generally do, right? I've been thinking about the slot conflict issue and am considering namespacing a class's keys against the class name and providing macros set-slot get-slot that transform into assoc and get respectively. If there are multiple slots with the same name the slot furthest down the inheritance chain is used. Perhaps also provide a function called prefer-slot which controls the behavior of the set-slot and get-slot macros. Dunno, starting to ramble, anyways, interesting stuff... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
