On Tue, Nov 4, 2008 at 1:45 PM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > > On Nov 4, 2:56 am, "Christian Vest Hansen" <[EMAIL PROTECTED]> > wrote: >> On Tue, Nov 4, 2008 at 6:23 AM, Mark H. <[EMAIL PROTECTED]> wrote: >> >> > On Nov 3, 6:48 pm, Cosmin Stejerean <[EMAIL PROTECTED]> wrote: >> >> I think clearly spelling out how objects of a type should be sorted is >> >> the point of the Comparable interface. >> >> > Ah, yes, this is true, I hadn't realized that String and Date both >> > implement Comparable. Comparable is supposed to impose a total >> > ordering on a set, so in a finite set of objects of the same type, the >> > max is always well defined. >> >> +1 on (min) and (max) operating on Comparables. >> > > Hmm... > > Do you want: > > (max 1 2.1 4/5) > > to work? > > If so, you can't base it on Comparable, which generally only supports > homogenous types.
"Generally" by custom but not required by contract of the Comparable interface. And those are all Numbers, right? Comparable imposes natural ordering, and the individual implementor is free to decide how to handle objects of different types; throwing a ClassCastException only being one of the possible reactions. > > max, like >, is a numeric operation as it stands, for the above and > speed reasons. If you want a general greatest/least based on > Comparable (or better yet Clojure's compare), I'm not opposed, but it > should probably be a different thing. I'm not the language designer here :) "greatest" and "least" are certainly more generic names, but min and max are short and to the point. If we had a greatest function, would it, for Numbers, be equivelant to max? If so, then that would be two ways to do one thing, which I'd generally be against. Performance is another thing. I had not considered the implications here. I can see many situations where max and min are expected to perform well for pure numeric parameter lists. On the other hand, I'd also like to push the responsibility down to the compiler to optimize :) (but I have a feeling that you won't be terribly keen on that idea) I guess my revised opinion is, that I don't see any conceptual or semantic problems, but the performance considerations might be enough to keep min and max as is. -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
