Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115687
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <e83810b6-2f34-450b-8715-587fb3f1d4b5@www.fastmail.com>
Date: Tue, 10 Aug 2021 23:46:22 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3D7F74C1-F1A0-4258-8EE3-3C143B6B54EB@newclarity.net>
References: <CAMrTa2EO-5nyoCYkHhMVxQ4nucRoHJj0=M=W22kUaW0jpHkHLg@mail.gmail.com>
 <f01eed58-6ccb-91a9-16d0-0f0c4e97d98a@gmail.com>
 <CAMrTa2E-pV+xP+3NJ=zd0S7N2agVRGiALaaJCBUaM=UwETEArw@mail.gmail.com>
 <94696d46-c4e6-406a-b859-89144bff31bf@www.fastmail.com>
 <D4BCCF3A-2DA1-4091-917D-7EBDB4A1AB5C@newclarity.net>
 <CAMrTa2GLQuVAKL089ykDJnBfVw=MNP-3qiTzHFpjQ8WTmUK+Lw@mail.gmail.com>
 <C2BA0FDB-2E9D-43CF-B63A-CE3C39B6EFB3@newclarity.net>
 <CAMrTa2HP8Q56qvcmAXe6W69OsSNwTNeFjRrP304G=ARubRxkZw@mail.gmail.com>
 <FE49BA62-2CAE-4446-AE56-B231A23015D3@newclarity.net>
 <CAMrTa2FNWg4bMo7uS+d_tKPVx8WkeaWs=kOEPF-4zSC7mnA4Xw@mail.gmail.com>
 <F925C8A6-84EB-43F5-A4D7-ED5CF4A02040@newclarity.net>
 <e83810b6-2f34-450b-8715-587fb3f1d4b5@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: mike@newclarity.net (Mike Schinkel)

> On Aug 10, 2021, at 10:22 AM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Point of order: I do not support a dedicated value-object/data-object =
construct, and have said so explicitly.  I support targeted tools that =
make using objects in that fashion cleaner and more robust.  (readonly, =
asymmetric visibility, clone-with, etc.)  Please do not misrepresent my =
position, especially when I've been fairly consistent on it.
>=20
> Also, one of the biggest failings of SPL is the degree to which it =
leverages and forces extension rather than interfaces.  Inheritance is a =
code reuse tool, NOT an architecture tool.  That's what interfaces are =
for.  We know this.  We've been bitten by this.  Building any kind of =
inheritance-based operator overloading into the language would be a =
terrible idea.  Let us never speak of it again.


Seems that you have chosen to callout a distinction and take offense =
to[*] that I was never intending.=20

When I referenced value objects the *how* was not the important part of =
my discussion but instead that fact that we do get there, evidenced by =
my use of "Or ???" when hypothesizing.

If the way PHP gets there is that a value object is an object where all =
non-private properties are explicitly declared readonly then that is as =
workable as if we explicitly define the class with a "value" keyword. I =
don't really care as I see it as a distinction without a difference.=20

Either way if PHP can identify a value object then it could limit =
operator overloads to just classes that are value objects by whatever =
approach PHP chooses to distinguish.


-Mike
[*] Ironically I mentioned you because I thought you would be appreciate =
seeing another reason PHP could benefit from value objects. But as they =
say, no good deeds go unpunished.=