[RFC] Comparable

php.internals

Fleshgrinder

9 years ago
Hi :) I have a few questions regarding the comparable RFC: https://wiki.php.net/rfc/comparable Couldn't find the thread in my history and thus cannot respond directly to any of the past threads. Maybe not that bad after more than a year of silence. :) My question might sound silly but I am genuinely interested in the explanation: why `compareTo` and not `comparedTo` as method name? Is it simply because of Java? To me it sounds kind of wrong: if ($this->compareTo($other) === -1) { } Especially if we add a nice Ordering Enum with some real behavior to the game: if ($this->compareTo($other)->isLess()) { } Compare this to: if ($this->comparedTo($other)->isLess()) { } This gets close to what I would understand as proper English. Then again there might be valid reasons for the former name that I am not aware of?!? There are other things that I think should be added along with this RFC. However, I need to investigate a bit further first before going into detail here.
-- Richard "Fleshgrinder" Fussenegger

Ryan Pallas

9 years ago
On Tue, Jan 31, 2017 at 3:48 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> Hi :) > > I have a few questions regarding the comparable RFC: > > https://wiki.php.net/rfc/comparable > > Couldn't find the thread in my history and thus cannot respond directly > to any of the past threads. Maybe not that bad after more than a year of > silence. :) > > My question might sound silly but I am genuinely interested in the > explanation: why `compareTo` and not `comparedTo` as method name? Is it > simply because of Java? To me it sounds kind of wrong: > > if ($this->compareTo($other) === -1) { } > > Especially if we add a nice Ordering Enum with some real behavior to the > game: > > if ($this->compareTo($other)->isLess()) { } > > Compare this to: > > if ($this->comparedTo($other)->isLess()) { } > > This gets close to what I would understand as proper English. Then again > there might be valid reasons for the former name that I am not aware of?!? >
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. Think about PDOStatement::fetch vs fetched, Exception::getMessage vs gotMessage. Honestly I can't think of a single example of a past tense method off the top of my head (doesn't meant they don't exist!). Even functions and language constructs are present (echo, require, print).

Rowan Collins

9 years ago
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,
-- Rowan Collins [IMSoP]

Fleshgrinder

9 years ago
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