Re: [RFC] Comparable

On 2/1/2017 2:44 PM, Rowan Collins wrote: > On 31 January 2017 23:02:07 GMT+00:00, Ryan Pallas > <derokorian@gmail.com> wrote: >> I would say compareTo makes sense, because that's what you're >> asking the method to do. Methods aren't usually past tense as it >> would seem weird. > > To be specific, methods are generally named as "imperative" phrases, > because they are instructing the object in question to do something. > Read the "->" as "I would like you to", and you get "$foo, I would > like you to compareTo $bar". > > The only real exception I can think of is boolean tests like "isFoo" > and "hasFoo", which are hard to put succinctly in imperative form > (Ruby instead uses the convention of "foo?"). "withFoo" is also > common, as shorthand for "getCloneWithFoo" - but note it doesn't have > a verb at all. > > Regards, > Thanks for the serious replies. I also found this nice article with a summary of many styles after a search regarding past tense, as mentioned by Ryan, in method names: http://blog.joda.org/2011/08/common-java-method-names.html I find it rather informative and the Joda project is a very respectable library too in the Java world. -- As I mentioned, there are other things that I think should be part of this RFC. The first thing that is definitely necessary is a dedicated exception. I would say that it should extend the InvalidArgumentException but that is up for debate. An appropriate name would be UncomparableException. > Two or more things that can’t be compared with each other are > uncomparable. Something that is so good that it is beyond comparison > is incomparable. Some dictionaries don’t list uncomparable, and your > spell check might say it’s wrong, but it’s a perfectly good, useful > word. It fills a role not conventionally filled by incomparable. > > http://grammarist.com/usage/incomparable-uncomparable/ Another thing that would be nice to have is an Ordering Enum type to get rid of the magic ]-1, 1[ numbers. This one should feature constants for the default values of -1, 0, and 1 as well as type safety for everything else like we have it for this kind of operations in Haskell or Rust. There is also the section in the RFC where it quotes Stas: > As a side note, if we have traits we might instead think of having > Comparable trait or interface or both, which would declare having > compareTo() standard feature (as Java does) without messing with the > engine and overloading operators. Surely, it would be more verbose, > but that might be a good thing. > > Stas In case we decide to do that we'll need more helper stuff do ease integration with existing functions like usort. That one any many others want a comparator callback, hence, there should be a convenient way to retrieve that from a Comparable instance. I will post a link with an actual userland implementation that illustrates better what I am talking about. -- Richard "Fleshgrinder" Fussenegger