Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108419
MIME-Version: 1.0
References: <00ea01d5d630$b18d4f20$14a7ed60$@gmx.de> <CAF+90c8h8dBhM=12ifxBJsWGcgVkjXHmmvKkPo_xCjUvZ++XdQ@mail.gmail.com>
 <001f01d5d7b3$68c18b10$3a44a130$@gmx.de> <7c915ed1-adcb-473d-a975-acfdbf7b1e33@www.fastmail.com>
 <B126CE02-402B-48EC-A46C-73D22CB74459@benramsey.com>
In-Reply-To: <B126CE02-402B-48EC-A46C-73D22CB74459@benramsey.com>
Date: Thu, 6 Feb 2020 15:29:16 -0500
Message-ID: <CAPKYkKwzP5dbihp+zQRSxJ_YepBkK_E9GjPrdn-Xs1S3dOjzNw@mail.gmail.com>
To: Ben Ramsey <ben@benramsey.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000032b31c059dee2171"
Subject: Re: [PHP-DEV] Operator overloading for userspace objects
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000032b31c059dee2171
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 31, 2020 at 10:55 AM Ben Ramsey <ben@benramsey.com> wrote:

> > Also, I want to reiterate: Any of these operations MUST be designed to
> return a new value, never modify in place.  These operators only make sense
> on value objects, not service objects, and value objects should be
> immutable.
>
> I completely agree. This was the gist of my earlier comments.
>
> Maybe we should resurrect discussion of the immutable classes and
> properties RFC: https://wiki.php.net/rfc/immutability
>
> If we add the ability to specify immutability, then we can enforce in the
> engine that the left and right operands must be immutable.
>
> For example:
>
> public function __add(immutable $left, immutable $right);
>
> Cheers,
> Ben
>
>
Ideally, I don't think the items have to be immutable. Here is a silly
use-case:
public function __add($left,$right){
    $left->operatedOn++;
    $right->operatedOn++;
    return $left->value + $right->value;
}

However, given the nature of operator overloading, I think the users should
EXPECT what they pass in will not be changed, unless they explicitly pass
by reference. This means we'd have to "change the rules" for operator
overloading magic methods, where objects are passed by value unless
explicitly passed by reference (  public function __add(&$left, &$right) ).
I think that is an even worse idea!

So, I think you really have two options. Change the rules so that even
objects are passed by value in this specific circumstance, and there is no
ability to pass by reference. I still don't like this, because it changes
the rules for only a specific scenario, but I think it's a better option
than the one above, as well as a better option than allowing mutable
objects 100% of the time - although, I'm not totally against spelling out
in the documentation "Don't modify the items passed in or you'll get
unexpected results!"

The other options is the immutability RFC. This doesn't change the rules -
it just adds a new rule. I don't see in that RFC, though, anything about
the immutable type hints. That's really the only thing that I think is
applicable to operator overloading.



-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000032b31c059dee2171--