Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115679
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>
In-Reply-To: <FE49BA62-2CAE-4446-AE56-B231A23015D3@newclarity.net>
Date: Mon, 9 Aug 2021 17:48:13 -0700
Message-ID: <CAMrTa2HcGQekMy2Fc-PiWeV2DK+-SXS-xhCYFjToK3fmYJGY0A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000049998d05c929db7d"
Subject: Re: [PHP-DEV] Revisiting Userland Operator Overloads
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--00000000000049998d05c929db7d
Content-Type: text/plain; charset="UTF-8"

 Apologies, this is being broken into two messages because of the 30000
byte limit on the list.

On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel <mike@newclarity.net> wrote:

>
> Improving documentation is an easier fix than adding a complex language
> feature. And a key difference is (almost?) anyone who is motivated can
> contribute to the docs; not so for adding language features.
>
> For example, why is it not an option for you to update the docs for
> DateTime and DateInterval if the docs are bad? Or other classes that have
> could have operator overloading in the future?
>
>
Oh absolutely. That's definitely worth doing and likely something that I
will contribute to over time, but it's not really the focus of this effort.


> So are you arguing that PHP should have no library functionality and have
> everything implemented in PHP?
>
> I don't mean to commit a reductio ad absurdum, but I am honestly confused
> by your need to see the implementation of behavior in PHP that is
> well-known and well-established in science and business.
>
>
No, it isn't a need. My point wasn't that documented library functions are
totally inadequate, it was that for incredibly specific things it is often
more useful to be able to consult your own codebase. Documentation is
great, and what I'm saying isn't that core implementations are bad because
then people need to consult the documentation. I was giving one of several
small reasons that I would prefer *this* feature inside a codebase if I
were deciding, and self-documenting code was just one of them. I'm sorry if
I gave the impression that the library or core features are less acceptable.

Anything that uses operator overloading will do so in a domain specific
way, that's the point of the feature. So to me, it makes more sense to
contain it in the same codebase if I'm given the option. That's all I'm
saying.


>
> Why it will be important to see operator overloading implementations in
> PHP when you don't see sin() and cos(), for example?
>
> This really feels like a personal preference and not a driving need for
> everyone. But if others agree that seeing operator overloading in PHP code
> is critical, please do speak up and, for my edification, please do explain
> why.
>
>
Funny story, I actually *did* need to consult the implementations for sin()
and cos(), but that was highly unusual and due to the specifics of the
library I was working on. My desire to see the operator overrides in user
code *is* a preference. Most things are in programming... I mean, Conway's
Game of Life is Turing complete, you could theoretically write a PHP
interpreter in *that*. And I don't say that to suggest that my feature
proposal is equally as important or simple as other things already in the
language, just that this isn't about the feature being critical (though in
some ways it is for particular domains), rather I am trying to *improve*
the language. This isn't an oversight or missing element from the language
I'm trying to patch, I'm just trying to make an earnest effort at something
that I believe will make the language better than it currently is. And
that's something that is inherently subjective I believe.


>
> Yeah, I don't see this as a problem.  Internally if there are a lot of
> similarities than the similarities can be shared by a common function.
>
> Duplication is not a problem in an of itself. If you only have to write it
> once and rarely ever need to maintain it.
>
>
Perhaps. Personally (and this is also something that is definitely a
preference), I find it a little unseemly to imagine DSL abstracts for a
random assortment of domains in the language. It gets the job done, it
doesn't require constant maintenance as you point out. I simply... find it
to be a lackluster result. I'll think about this at more length to see if I
can concretely describe why.


>
> That is in part of why I asked for use-case examples, to see if there
> really were a lot of use-cases where operator overloading makes sense.  You
> only provided two categories; Math and the already existing DateInterval.
>
>
This seems... a bit reductionist? I suppose if you consider anything that
has a numeric value "math", then sure.

Math is extremely large. Geometry is very different from matrices, which is
very different from arithmetic, which is very different from complex
numbers.

Again, I'm providing those examples because I can literally bring up code
from my own libraries for those, so I'm a good advocate for them. But
others certainly exist. I think you would throw this under "math", but what
about unit-based values? If you wanted to do `19cm + 2m`, you could return
`219cm`, or `2.19m`, or `2190mm`. Supposing that there was an abstract, how
would it know what unit conversion to use? Or what about `2km + 4mi`? Or
what about erroring for `2km + 4L`?

These are *certainly* more common in general PHP applications than my own
math library examples.

Another good example of unit based values would be online stores
controlling inventory and carts. You could have item ID's be the 'unit' to
control them, or perhaps you 'unit' them by their shipping size. Or perhaps
store items actually have several units attached to them, so that you could
automatically combine shipping volumes and weights, while in other
locations combining quantities and prices.

All of these things are *possible* in PHP. This doesn't enable those
things. But it makes them cleaner and easier to reason about, and reduces
the code necessary to accomplish them.


>
> The one and only comment expresses the commenter's opinion, not "why it's
> incorrect."  You dismiss the author you disagree with who wrote a full post
> that also references why the Go language designers choose to avoid operator
> overloading but you attribute much greater authority to the drive-by
> commenter who simply states an opinion you agree with.
>
> When it boils down to it, it's all just opinion.  But I posting his link
> because you strong implied that nobody has issues with operator overloading
> in Python while that post illustrates that some people do have issues with
> operator overloading in Python.
>
>
Right, that's fair. I was suggesting that I hadn't seen a consensus or
discontent around Python's implementation of operator overloads, not that
it doesn't exist. That particular article seems to be based on "Go says
operator overloads are complicated so they should exist" (apologies for my
own reductionist summary). Yet Go is essentially built around routines and
concurrency which is an incredibly complicated feature. I think that there
is certainly complexity in operator overloads, but I feel (and will attempt
to demonstrate with this RFC) that the benefits are worth the complexity.


>
> Honest question:  If Python is so much better for math and you appear to
> be a math guy, why are you using PHP?  What are your use-cases where you
> can't just use Python?
>
>
Well, the first answer would be that I use PHP for my day job. I also use
Python, but much more sparingly. Python can accomplish all the things that
I want to do... I mean NumPy and SciPy exist and cover virtually every math
case that has even been hinted at so far in this thread. But PHP is the
language I enjoy the most. That at its core is why I started writing a math
library for PHP years ago. I like the language, and I want it to be better,
and I wanted to contribute something to help people accomplish goals that
were difficult to accomplish in the language. That's still my motivation
now, and that's one of the things I hope to achieve with this RFC.

R and Haskell are also very capable math languages, yet all three languages
are used. I don't think the idea that another language has better tools for
a particular task is an argument against making PHP more capable at that
task.

Jordan

--00000000000049998d05c929db7d--