Hello, Am 06.02.2009 um 09:34 schrieb mikel:
(prefer-method frob ::idea ::thing)(prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing]) (prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea]) Provide a dispatch fn that extracts the runtime tag.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...). Maybe one new entry in the preferTable per created thing is not too burdensome with a few million objects. That dispatch value kind of hurts my eyes, though.
Maybe the remedy for this is issue is per-defmulti hierarchies. So one can define for each method a hierarchy and the runtime tag derives from the preferred tag. (defthing a [::modelA] [::idea ::thing]) (defthing b [::modelB] [::thing ::idea]) So for a there might be a runtime-tag ::runtime_tag__4711_ which simply derives from ::idea. For b ::runtime_tag__0815_ derives from ::thing. Since the hierarchies are per defmulti a and b might have a different version for one method and the same for another. On the issue list there is a patch for per-defmulti hierarchies, waiting for Rich's approval. Although it's not predicate dispatch it might help to bridge the time until the SoC project gives us predicate dispatch. Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature
