> ((String)x).length. There's no need to unify the types. There's > nothing 'bad' about the code above, that's why we're using Lisp - the > type systems are still struggling to be expressive enough. If some > third class had both methods, that would become the preferred branch.
I actually hadn't thought of casting. That does make more sense than restricting the method type since it avoids reflection without forcing a specific nominal type. I wasn't saying anything about bad-boy being an example of "bad coding". I like type systems, but this is a dynamic language, one where things like that are idiomatic and no cause for concern. I was just trying to use an obviously untypeable function to illustrate my point. The problem I see with trying to infer different types along different branches is there is nothing to stop me from creating different branches without directly involving a known conditional construct: (defn my-cond [pred then else] (if pred (then) (else))) (defn bad-boy [c x] (my-cond c #(.getMethods x) #(.length x))) I don't see that you would be able to infer the separate paths for this in the general sense. I suppose though that just recognizing (if ...) and acting accordingly is a step in the right directly without actually breaking anything else. Cases like (my-cond ...) could either be left as reflection or unified (if unambiguous). > There's no need to go there, IMO. What I've described would be > relatively simple and effective. Just spinning ideas, looking to see where performance can be had while simultaneously trying to wrap my head around the approach you suggested. I still think that tracing (even in a limited form) could bring some serious performance gains on hard-hit code paths where reflection could not be avoided, but maybe that's a thought for another day. Even if you did want to go with a tracing-based approach, the overhead of bottling that analysis onto the JVM would probably outweigh most gains. And as you said, there's no need to go there. Daniel --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---