> ((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
-~----------~----~----~----~------~----~------~--~---
