On Tue, Aug 10, 2021 at 12:15 AM Mike Schinkel <m...@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. > > • Length e.g. meters > • Time e.g. seconds > • Amount of substance e.g. moles > • Electric current e.g. amperes > • Temperature e.g. kelvin > • Luminous intensity e.g. candela > • 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 have > 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 to > 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 may > well make PHP less capable for those who want to write robust and reliable > 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. Would > 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 — it would be perfectly reasonable > IMO for you wanting features to enhance your library vs. eliminate the need > for it — 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
