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 <m...@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
