Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8478e9f9-6f03-fc54-30f3-7ba27314f82b@fleshgrinder.com>
References: <CAA69SC5w-0KAGcX_akmhtFJL=mte+3ZrShKPtnWgcML+z-HhKw@mail.gmail.com>
 <83fa661e-2d3d-6548-a506-fb969be31c0e@garfieldtech.com> <CAA69SC4=BXomSjmwm_6AEQGWqQqDC9scCVfv0aDH_rXMdZwt2A@mail.gmail.com>
 <c179bdb7-8665-9998-6f4f-99bbbfd19131@fleshgrinder.com> <CABdc3Wq_zfifnU=Y7TY8AXakBNO_KyDxaMhk0+Kubao_wGXaTg@mail.gmail.com>
 <56acc1d9-f424-a460-59be-3a9a1a74b198@fleshgrinder.com> <e06a39a8-305a-2de1-a8a7-e249d8179b09@gmx.de>
 <CAA69SC7wzKc2djTX267gaVpKd5-28H_GwAq2UBpzpRrqUfjpKQ@mail.gmail.com>
 <CAA69SC4QHSPpTo69X8siUv9gNmWdkgiBoiFE9Dsv_7n+Hnkpmw@mail.gmail.com>
 <b5f4cdb7-ab12-e508-5e1d-03d55db4eca0@gmx.de> <95832b08-ee80-18c1-a3da-202eed51903e@fleshgrinder.com>
 <2c115733-8fe4-5230-a9ec-9d5f2cc2b810@garfieldtech.com> <d4ccd291-f866-d510-7bbd-a4c5cf1a49e3@fleshgrinder.com>
 <B7D1AED9-DF6D-4118-BBEA-29243D99C0E8@koalephant.com> <06ce2daf-4112-3464-b6d6-47f1ece05303@garfieldtech.com>
 <8478e9f9-6f03-fc54-30f3-7ba27314f82b@fleshgrinder.com>
Date: Tue, 13 Sep 2016 09:40:27 +0200
Message-ID: <CABdc3WphzT4pJb-xABeR=b2F2KQtt=DoqG3gutfOFdTAQiWy-A@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Cc: Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary=94eb2c03e28a02f318053c5ebae6
Subject: Re: [PHP-DEV] RFC - Immutable classes
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c03e28a02f318053c5ebae6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Proposed operator overloading and magic methods to compare with other
objects
is very good idea, I like it a lot, there even may be additional
restriction provided
with my other RFC https://wiki.php.net/rfc/object-typehint

But I think this goal should be provided in separate RFC as it is very
usefull in
immutable objects, but also will be in mutable objects. While this is not
required
to introduce immutable objects I thinkk it should be in separate RFC.

2016-09-13 8:40 GMT+02:00 Fleshgrinder <php@fleshgrinder.com>:

> Thanks a lot for your feedback.
>
> I like the clone idea too and I also see no harm in allowing them in any
> context rather than only in immutable classes. I am really against the
> transformer keyword, don't ask me why, I just don't like it at all. :P
>
> I mentioned before that PHP should allow for operator overloading since
> there are other value object use cases that are even simpler than your
> HTTP header result: any value object that is case insensitive. Doh!
>
> I do like the https://wiki.php.net/rfc/comparable RFC but we would need
> more for value objects to be truly useful.
>
>   class A {
>
>     // $this =3D=3D $other
>     function __isEqual($other);
>
>     // $this =3D=3D=3D $other
>     function __isIdentical($other);
>
>   }
>
> This will be very hard to get through though because it's operator
> overloading. I am currently already doing this in many of my value
> objects, although I usually implement an equals method only and let it
> take care of equals and identity checks at the same time.
>
>   final class HexNumber {
>
>     private $val;
>
>     public function __construct(string $hex) {
>       $this->val =3D strtolower($hex);
>     }
>
>     public function equals($other) {
>       if ($other instanceof self) {
>         return $other->val =3D=3D=3D $this->val;
>       }
>
>       if (is_string($other)) {
>         return strtolower($other) =3D=3D=3D $this->val;
>       }
>
>       return false;
>     }
>
>   }
>
>   $hn =3D new HexNumber('ff00');
>   var_dump($hn->equals('FF00')); // bool(true)
>
> However, this is not necessarily exactly what you want in every context,
> hence, the proposal for operator overloading.
>
> That being said, I agree that this could (and probably should) be
> tackled in another RFC. Immutable classes do not have to solve every
> problem.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
brzuchalski.com

--94eb2c03e28a02f318053c5ebae6--