Le 06/08/2021 à 18:34, Jordan LeDoux a écrit :
Hey all,
...
Hello,
I'm sorry I couldn't answer the last few weeks I was on vacation.
I just wanted to say, I'm opposed to user-land operator overloading for
a few reasons:
* it may produce shorter, simpler code, but it hides the real logic
On 08-08-2021 09:41, Jordan LeDoux wrote:
> Off the top of my head here are some of the use cases that I think benefit
> greatly from this:
>
> - Complex number objects
> - Fractions objects
> - Matrix objects (math)
> - Vector objects (math)
> - Time/Date intervals
> - Collections
> - Arbitrary p
> On Aug 11, 2021, at 5:25 AM, Jordan LeDoux wrote:
>
> I want to avoid this. :) The implementations in my actual math libraries are
> much more thorough and thought out. This is an example. If people want to see
> something that is closer to what would actually be done in a library, they
> sh
On Wed, Aug 11, 2021 at 1:42 AM Mike Schinkel wrote:
>
> It that what you envision? To create a ComplexNumber() do I first need to
> wrap in Real() and in Imaginary()? Or where you intending I could just
> pass numeric literals? If yes, PhpStorm said your type hints did not allow
> it.
>
>
In t
> On Aug 11, 2021, at 12:06 AM, Jordan LeDoux wrote:
>
> Here is a quick and dirty example of just the complex number use case. It
> assumes that the operator overloads already are built in. A couple of
> things of note:
Excellent. Thank you for taking the time to do this. Very helpful.
One th
On Tue, Aug 10, 2021 at 8:46 PM Mike Schinkel wrote:
>
> 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
> On Aug 10, 2021, at 10:22 AM, Larry Garfield wrote:
>
> 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
> visibi
On Tue, Aug 10, 2021, at 1:51 AM, Mike Schinkel wrote:
> 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.
>
> What if we had a new type of class that is to be used only for va
On Tue, Aug 10, 2021 at 12:15 AM Mike Schinkel 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 somet
> On Aug 9, 2021, at 8:40 PM, Jordan LeDoux wrote:
> 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...
On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel wrote:
> However, you are actually making my point, which is that since they are so
> deterministic then why is there the need for flexibility to be done in
> userland vs. the standardization that could be could be better in PHP core?
> For the latter
Apologies, this is being broken into two messages because of the 3
byte limit on the list.
On Mon, Aug 9, 2021 at 2:32 PM Mike Schinkel wrote:
>
> Improving documentation is an easier fix than adding a complex language
> feature. And a key difference is (almost?) anyone who is motivated can
On Aug 9, 2021, at 5:32 PM, Mike Schinkel wrote:
> On Aug 9, 2021, at 1:48 PM, Jordan LeDoux wrote:
> You claim that this would be documented on php.net and this would be
> sufficient. Yet the DateTime class has had operator overloads for comparison
> operators since 5.2 and there is still *ze
On Mon, Aug 9, 2021 at 11:40 AM Peter Cowburn wrote:
> On Mon, 9 Aug 2021 at 18:48, Jordan LeDoux
> wrote:
>
>>
>> You claim that this would be documented on php.net and this would be
>> sufficient. Yet the DateTime class has had operator overloads for
>> comparison operators since 5.2 and there
On Mon, 9 Aug 2021 at 18:48, Jordan LeDoux wrote:
>
> You claim that this would be documented on php.net and this would be
> sufficient. Yet the DateTime class has had operator overloads for
> comparison operators since 5.2 and there is still *zero* mention on
> php.net
> (that I am aware of or c
On Mon, Aug 9, 2021 at 3:49 AM Mike Schinkel wrote:
> 1. When you speak of "not documented in the code" do you mean the
> implementation would not be in PHP code? Okay, yet none of these functions
> are documented in PHP code and they are all available in PHP:
>
> https://www.php.net/manual/en/re
> On Aug 8, 2021, at 3:41 AM, Jordan LeDoux wrote:
>
> Off the top of my head here are some of the use cases that I think benefit
> greatly from this:
>
> - Complex number objects
> - Fractions objects
> - Matrix objects (math)
> - Vector objects (math)
> - Time/Date intervals
> - Collections
>
On Sun, Aug 8, 2021 at 9:52 AM Rowan Tommins
wrote:
>
> Yes, and as I demonstrated, there are situations where some of the
> operators are only meaningful for a subset of operands. Saying that a
> Money object is "Multipliable" would also be "a lie", since multiplying
> two Money objects together
On 08/08/2021 16:39, Larry Garfield wrote:
1) Implementing an interface and stubbing out some methods is a lie. It's a lie
the engine won't stop you from telling, but it's still a lie. If you only
support addition and division, for instance (add to a collection and split a
collection into sev
Responding to a bunch of people at once here, for simplicity:
On Sat, Aug 7, 2021, at 7:04 PM, Jordan LeDoux wrote:
> > The 4 arithmetic operators, concat, and compare.
>
> I would argue that both modulo and pow (% and **) are arithmetic operators
> that should come with the basic four as well.
On 08/08/2021 08:41, Jordan LeDoux wrote:
Off the top of my head here are some of the use cases that I think benefit
greatly from this:
- Complex number objects
- Fractions objects
- Matrix objects (math)
- Vector objects (math)
- Time/Date intervals
- Collections
- Arbitrary precision numbers (
On Sun, Aug 8, 2021 at 3:08 AM Deleu wrote:
> I started reading this thread with a total bias against it and as I read
> through it I can only imagine how painful and annoying it is to maintain a
> math library in PHP. Operator Overloading is truly a marvelous piece of
> functionality for that do
I started reading this thread with a total bias against it and as I read
through it I can only imagine how painful and annoying it is to maintain a
math library in PHP. Operator Overloading is truly a marvelous piece of
functionality for that domain.
However my biased still exists: it would be awf
On Sat, Aug 7, 2021 at 8:20 PM Mike Schinkel wrote:
> > On Aug 7, 2021, at 10:28 AM, Larry Garfield
> wrote:
> I strongly echo Larry's concern here.
>
> While I tend to be one who wants more language features, not less, the
> availability of unconstrained operator overloading can beckon an
> ine
On Sat, Aug 7, 2021 at 8:26 PM Dusk wrote:
> On Aug 7, 2021, at 15:28, Larry Garfield wrote:
> > As an example here, time units. Adding two hour:minute time tuples
> together to get a new time (wrapping at the 24 hour mark) is an entirely
> reasonable thing to do. But multiplication and divisi
On Aug 7, 2021, at 15:28, Larry Garfield wrote:
> As an example here, time units. Adding two hour:minute time tuples together
> to get a new time (wrapping at the 24 hour mark) is an entirely reasonable
> thing to do. But multiplication and division on time doesn't make any sense
> at all. O
> On Aug 7, 2021, at 10:28 AM, Larry Garfield wrote:
>
> The downside is that 30 seconds after that, 15 other libraries would do the
> same in subtly incompatible ways, and then both Laravel and Symfony would
> release their own that are incompatible with each other, and it would just be
> a t
On Sat, Aug 7, 2021 at 3:29 PM Larry Garfield
wrote:
>
> Side note: Please remember to bottom-post.
> (trimmed message)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Sorry about top-posting. :)
Your
On Sat, Aug 7, 2021, at 3:07 PM, Jordan LeDoux wrote:
> > a) Treating operators as arbitrary symbols, which can be assigned any
> operation which makes sense in a particular domain.
> > b) Treating operators as having a fixed meaning, and allowing custom
> types to implement them with that meaning.
> a) Treating operators as arbitrary symbols, which can be assigned any
operation which makes sense in a particular domain.
> b) Treating operators as having a fixed meaning, and allowing custom
types to implement them with that meaning.
I think this is the core design choice that will affect how
On 06/08/2021 17:34, Jordan LeDoux wrote:
1. The only supported operators in the RFC will be the mathematical
operators: (+, -, /, *, **, %)
2. The RFC would also provide an interface, (something like
MathObjectInterface), that has all the magic methods in it.
3. The do_operation would be changed
On Fri, 6 Aug 2021 at 21:18, Scott Arciszewski wrote:
>
> It's probably worth exploring whether common combinations are worth
> defining for convenience.
>
My understanding of the current consensus is "let's not".
That's based from the discussion on whether defining 'number' as 'int
| float' wou
On Fri, 6 Aug 2021 at 17:34, Jordan LeDoux wrote:
>
> I was considering working from Jan's previous
> implementation with these basic changes:
That may not be the best place to start, and that something more
similar to the previous (unvoted) RFC may be better:
https://wiki.php.net/rfc/operator-ov
On Fri, Aug 6, 2021, at 3:18 PM, Scott Arciszewski wrote:
> My recommendation is to have a base interface for every operator that can
> be overloaded, so that these can be composed together.
>
> AddOverloadInterface { __overloadAdd(): self; }
> SubOverloadInterface { __overloadSub(): self; }
> Mul
My recommendation is to have a base interface for every operator that can
be overloaded, so that these can be composed together.
AddOverloadInterface { __overloadAdd(): self; }
SubOverloadInterface { __overloadSub(): self; }
MulOverloadInterface { __overloadMul(): self; }
DivOverloadInterface { __
On Fri, Aug 6, 2021, at 11:34 AM, Jordan LeDoux wrote:
> Hey all,
>
> I contacted Jan a few days ago to ask if they were going to try again for
> their RFC, but I wanted to get a quick temperature check on this.
>
> I would like to work on this RFC for 8.2, and after going through previous
> disc
36 matches
Mail list logo
