Missing equalTo() method

[beberlei]

Sometimes i want to compare enums for equaility, currnetly i have to cast to (string) to make it work. This could be something to add as a default method.

[mnapoli]

Yep that would definitely make sense!

[mnapoli]

See also #8 you can use ==:

if ($enum == MyEnum::FOO()) {
}

So in the end I'm not sure a equalTo() method is necessary?

[mirfilip]

@mnapoli I was about to write the same yesterday.

[mnapoli]

OK closing for now.

[notfalsedev]

+1 for a 'equalsTo' method.
It's much easier to use.

public function equalsTo($enum)
{
  return $this == $enum;
}

$enum1 = Enum::KEY_ONE();
$enum2 = Enum::KEY_TWO();

$enum1->equalsTo($enum2); (false)
$enum1->equalsTo($enum1); (true)

[jeremykendall]

I was looking for this functionality last night. Added PR #39 + a test.

[mnapoli]

#39 has been merged, I'll give it a day or two for everyone to review (given how used the library is) and then I'll tag 1.5.0

Thanks @jeremykendall

[jeremykendall]

@mnapoli You're welcome! Thanks for letting me contribute!

[mirfilip]

@mnapoli @jeremykendall My team and I use this library as a base for our own enum library (a wrapper, you can call it) and we tend to add features that seems necessary for us and maybe doesn't warrant the inclusion to php-enum itself. With that intro, I'll share our insights cause we've discussed "equals in php" problem couple of times:

The need for equals method is most visible to (ex-)Java programmers who wander to php valley. I consider Java functionality of comparing objects a good mechanism and is considered so by Java community in general (afaik, never seen people complaining). I'm talking about equals + hashCode flexibility. This post provides an easy walkthrough on functionality. See this question as an exactly the same question we have here, just in Java world.

The beauty there is "equals defers to ==". That means, if you don't override it, both will work the same way. Also, Java internals use equals method to compare objects which means you can change it's done by overriding equals or hashCode (the latter being the blessed way).

Back to PHP, that's not how it works. PHP internals will almost always use ==. So what? Indeed, there is no difference in standard case:

final class Color extends \MyCLabs\Enum\Enum {
    const RED = 'red';
    const BLUE = 'blue';
}

$red = COLOR::RED();
$blue = COLOR::BLUE();

$anotherRed = COLOR::RED();

// Equality check using == // expected
var_dump($red == $red); // true
var_dump($red == $blue); // false
var_dump($red == $anotherRed); // true

// Equality check using equals() // expected
var_dump($red->equals($red)); // true
var_dump($red->equals($blue)); // false
var_dump($red->equals($anotherRed)); // true

All good, there is no blessed equality checking method, user uses whichever preferred.

Then, user goes and overwrites the equal method ("because reasons") and both methods stop producing the same results. Having that, it's a matter of time for bugs to start cropping in cause the user is accustomed to using both method interchangeably.

There is a simple fix which would make the design of that feature better - declare the equals method final. That way, you can't simply extend this library, make mess and blame the library - if you want some flexibility and you know what you're doing - go with composition.

Maybe I'm being picky now, but that's what I expect from a good enum library in php if it introduces a third way of comparing objects. Not only enum library, the same goes for value objects.

btw. another way of solving that is going full-Java:

abstract class JavaLikeEnum extends \MyCLabs\Enum\Enum {
    final public function equals(\MyCLabs\Enum\Enum $outsider)
    {
        return $this->hashCode() == $outsider->hashCode();
    }

    protected function hashCode() {
        return $this->getValue();
    }
}

if you want to change what equals means, go after hashCode, don't touch equals. Anyhow, both your method and the one I proposed bring an additional comparison method that bring no added functionality, just confusion in the long run.

[mnapoli]

@mirfilip right that's an interesting POV. Making the method final would make sense. And as @Ocramius would say it's easier to remove final than to add it so it's safer to go this way at first.

Thoughts anyone?

[jeremykendall]

I'm always game for final and would be happy to amend the PR.

Awesome input, @mirfilip!

On Wednesday, October 5, 2016, Matthieu Napoli notifications@github.com
wrote:

@mirfilip https://github.com/mirfilip right that's an interesting POV.
Making the method final would make sense. And as @Ocramius
https://github.com/ocramius would say it's easier to remove final than
to add it so it's safer to go this way at first.

Thoughts anyone?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#4 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARnZet3bTMOy5V59pSijOdzznCr4b1jks5qw9rhgaJpZM4CaGob
.

Sent from Gmail Mobile