Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115682
MIME-Version: 1.0
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>
In-Reply-To: <F925C8A6-84EB-43F5-A4D7-ED5CF4A02040@newclarity.net>
Date: Tue, 10 Aug 2021 00:59:42 -0700
Message-ID: <CAMrTa2GS9PSt=6EPVGZ=pXRmTABx=4PE7ytFAZqR8EFkQ+jRoA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005e94b105c92fe200"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000005e94b105c92fe200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 10, 2021 at 12:15 AM Mike Schinkel <mike@newclarity.net> wrote:

>
> So that gives me two (2) thoughts
>
> 1.) First is Geometry would be another area for PHP to consider adding
> classes.
>
> 2.) Then I thought: What if PHP had the ability to explicitly define
> *value* objects?  I know this has been something Larry Garfield has
> mentioned[1] in the past.
>   ...

Can you see any reason why only allowing the addition of operator overloads
> to *value* objects would too limiting?
>
>
Hmmm. My immediate suspicion is that the technical details of how to make
an object that *could* do this would be devilishly difficult. However, as
an alternative to my proposal, it also has a year, so it's something we
should explore. I think that if this were done very, very carefully, it
would cover 80-90% of use cases, so it's worth exploring as part of my
background and research for this RFC.


>
>         =E2=80=A2 Length e.g. meters
>         =E2=80=A2 Time e.g. seconds
>         =E2=80=A2 Amount of substance e.g. moles
>         =E2=80=A2 Electric current e.g. amperes
>         =E2=80=A2 Temperature e.g. kelvin
>         =E2=80=A2 Luminous intensity e.g. candela
>         =E2=80=A2 Mass e.g. kilogram
>
> Those seem like a great *finite* list of fundamental units I would argue
> PHP could benefit userland developers greatly by adding *standardized*
> classes to handle them, maybe in a `PHP\Units` namespace.  We already hav=
e
> Time.
>
> Then I can envision a `Value` base class, trait(s) and/or interfaces that
> could support generic unit conversion that these specific units, like
> Length.  1 'm' could be defined equal to 100 'cm' and then this could be
> possible:
>
>
Interesting! So the reason I actually started work on my math library was
to support arbitrary precision math for my units/physics library,
samsara/newton. I haven't updated it in about 8 years so it is... not a
stellar example of the implementation, however handling this behavior is
exactly what my library was for. There are at least two more: plane angle
and solid angle. Plane angle is used in composition of units such as
angular acceleration (plane angle / time^2), while solid angle is used in
composition of the units for illumination (luminous intensity * solid angle
/ length^2).


>
> I'd argue for the shopping cart example it would make it more difficult t=
o
> reason about for the very reason that you gave three different potentials
> for how to define a unit.
>
> As for Length being appropriate for operator overloading, absolutely.
>
>
In a library situation yes, I was more talking in business solutions.
Businesses that run their web application in PHP will build something that
is obtuse to other people, because an individual business is usually obtuse
to people who are not in that business. So I agree that you are correct,
but I don't think there's any preventing that. That's just the nature of
having millions of different programs written in the language IMO.


>
> However, that debate is a digression from our topic so we shouldn't
> further it here.
>
>
Fair.


>
> Unless adding those tools make it less capable at the tasks its best for.
> And I am arguing that adding generic operator overloads for all classes m=
ay
> well make PHP less capable for those who want to write robust and reliabl=
e
> web applications.
>
> (If we add value object classes and add generic operator overloads there,
> I feel much less concerned about PHP becoming less capable of achieving
> robustness and reliability.)
>
>
Ah, okay. This is the first clear articulation of *what* the issue might
be. Now I will be able to investigate it properly, thank you. :)


>
> One final question.  Let's assume that the functionality in your library
> were to be added to PHP such that your library was no longer needed.  Wou=
ld
> you be fine with that, or do would you prefer that features added to PHP
> made your library more attractive as opposed to no longer needed?
>
> I'm not suggesting anything untoward =E2=80=94 it would be perfectly reas=
onable
> IMO for you wanting features to enhance your library vs. eliminate the ne=
ed
> for it =E2=80=94 I am just interested to know which avenue you would find=
 most
> compelling?
>
>
I wrote my math library because I found it necessary to support the
units/physics library that I was writing and couldn't find an acceptable
library for it. It was originally a means to an end. The units/physics
library I originally started writing because I wanted to write a web-based
game that people could play, and needed the units library for the kind of
server simulation that I needed to run.

I have actually multiple times considered translating my own math library
to an extension or an RFC. I would have no issue with inclusions to core
making my libraries obsolete. I've been working on them for 11 years and
they are still not finished, it would be honestly amazing if PHP did
support or had supported what I needed to do already.


>
> P.S. I've seen when language features are added that eliminate the need
> for selected domain-specific libraries it can actually give the library
> author room to provide even more specific functionality and increase the
> library's value and thus increase the library's adoption, rather than
> killing it. #fwiw
>
>
I think this is likely the case with my library. I branched it out to add
things like rounding modes, including things like stochastic rounding which
are important for machine learning applications. I also added PHP
implementations of statistics functions, since ext-stats has been abandoned
for several years. If the core math was supported, I could probably focus
on just providing the statistics module, or I could focus on extending
bcmath that so that it supported trigonometry, or I could focus on many
other aspects. I am unconcerned with the idea that core will make all my
work obsolete because I am 100% certain that the amount of features I've
written will never be included in core... the RFC to do so would be an
endless stream of questions, the implementations would be complex and
difficult for most people to reason about because they would require
extremely strong algorithmic understanding *and* extremely strong math
understanding.

My library basically reimplements the entire PHP standard math library for
arbitrary precision numbers, including all trig functions, hyperbolic trig
functions, inverse trig functions, logs, euclidean coordinate systems... it
would be like doubling the entire math library of PHP, which I highly doubt
would ever pass a vote.

Jordan

--0000000000005e94b105c92fe200--