On Tue, 21 Dec 2021 at 23:20, Jordan LeDoux wrote:
>
>
>
> On Tue, Dec 21, 2021 at 5:47 AM Andreas Hennings wrote:
>>
>> I see the "Implied Operators" section.
>> I assume this means that a new instance will be created, and stored on
>> the same variable, _if_ the original operator is written in
On Tue, Dec 21, 2021 at 5:47 AM Andreas Hennings
wrote:
> I see the "Implied Operators" section.
> I assume this means that a new instance will be created, and stored on
> the same variable, _if_ the original operator is written in an
> immutable way (which it should be)?
>
> E.g.
>
> $money =
On Tue, 21 Dec 2021 at 02:57, Jordan LeDoux wrote:
>
>
>
> On Mon, Dec 20, 2021 at 4:43 PM Andreas Hennings wrote:
>>
>> > The exact position of where that trade-off is 'worth it' is going to
>> > be different for different people. But one of the areas where PHP is
>> > 'losing ground' to Python
On Tue, 21 Dec 2021 at 10:13, Rowan Tommins wrote:
>
> On 21/12/2021 00:43, Andreas Hennings wrote:
> > I think the example in the RFC is interesting, but not ideal to
> > advertise the RFC.
> > The example is with native scalar types and build-in operator
> > implementations.
> > (I don't know
On 21/12/2021 00:43, Andreas Hennings wrote:
I think the example in the RFC is interesting, but not ideal to
advertise the RFC.
The example is with native scalar types and build-in operator implementations.
(I don't know how GMP works internally, but for an average user of PHP
it does not make
On Tue, Dec 21, 2021, 6:37 AM Andreas Hennings wrote:
>
> In a class Matrix, you might want to implement three variations of the
> * operator:
> - Matrix * Matrix = Matrix.
> - Matrix * float = Matrix.
> - Matrix * Vector = Vector.
> Same for other classes and operators:
> - Money / float =
On Mon, Dec 20, 2021 at 4:43 PM Andreas Hennings
wrote:
> > The exact position of where that trade-off is 'worth it' is going to
> > be different for different people. But one of the areas where PHP is
> > 'losing ground' to Python is how Python is better at processing data
> > with maths, and
On Tue, 21 Dec 2021 at 00:03, Dan Ackroyd wrote:
>
> On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote:
> >
> > When reading
> > this code: $foo * $bar - how do I know which of the ways you took and
> > where should I look for the code that is responsible for it? When I see
> >
On Fri, 17 Dec 2021 at 00:25, Larry Garfield wrote:
>
> On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:
>
> > I see the distinction in overloading based on the object type on the
> > left, vs overloading based on parameter types.
> >
> > For a method call $a->f($b), the implementation
On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote:
>
> When reading
> this code: $foo * $bar - how do I know which of the ways you took and
> where should I look for the code that is responsible for it? When I see
> $foo->times($bar) it's clear who's in charge and where I find the code.
>
On 17/12/2021 22:04, Jordan LeDoux wrote:
In general, unioning types should be seen as a "code smell" with this
feature in my personal opinion. If you start to see 4, 5, 6 different types
in your parameters, it should be a signal that you want to re-examine how
you are implementing them. I think
On Fri, Dec 17, 2021 at 12:26 PM Matt Fonda wrote:
>
> Thanks for the info. I share Stas's unease with having many different
> places we must look in order to understand what $foo * $bar actually
> executes. I'm also uneasy with the requirement of union typing in order for
> an operator to
Hello internals,
>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
>register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
>But this just brings a new set of problems, including visibility issues
>(i.e.
On Fri, Dec 17, 2021 at 10:37 AM Jordan LeDoux
wrote:
> On Fri, Dec 17, 2021 at 9:43 AM Matt Fonda wrote:
>
>> Hi Jordan,
>>
>> Thanks for the RFC. I have a couple questions:
>>
>> Suppose I have classes Foo and Bar, and I want to support the following
>> operations:
>>
>> - Foo * Bar (returns
On Fri, Dec 17, 2021 at 10:36 AM Stanislav Malyshev
wrote:
> And that's one of the reasons I feel so uneasy with this. When reading
> this code: $foo * $bar - how do I know which of the ways you took and
> where should I look for the code that is responsible for it? When I see
>
On Fri, Dec 17, 2021 at 9:43 AM Matt Fonda wrote:
> Hi Jordan,
>
> Thanks for the RFC. I have a couple questions:
>
> Suppose I have classes Foo and Bar, and I want to support the following
> operations:
>
> - Foo * Bar (returns Foo)
> - Bar * Foo (returns Foo)
>
> If I understand correctly,
Hi!
On 12/17/21 9:43 AM, Matt Fonda wrote:
Hi Jordan,
Thanks for the RFC. I have a couple questions:
Suppose I have classes Foo and Bar, and I want to support the following
operations:
- Foo * Bar (returns Foo)
- Bar * Foo (returns Foo)
If I understand correctly, there are three possible
Hi Jordan,
Thanks for the RFC. I have a couple questions:
Suppose I have classes Foo and Bar, and I want to support the following
operations:
- Foo * Bar (returns Foo)
- Bar * Foo (returns Foo)
If I understand correctly, there are three possible ways I could implement
this:
a) Implement the *
On Thu, Dec 16, 2021 at 4:21 AM Andreas Hennings
wrote:
>
> Having one side of the operator "own" the implementation feels wrong,
> and could lead to problems with inheritance down the line.
>
> From C++ I remember that at the time, there was a philosophy of
> defining and implementing these
On Thu, Dec 16, 2021, at 1:24 PM, Andreas Hennings wrote:
> I see the distinction in overloading based on the object type on the
> left, vs overloading based on parameter types.
>
> For a method call $a->f($b), the implementation of ->f() is chosen
> based on the type of $a, but not $b.
> For an
On Thu, 16 Dec 2021 at 19:20, Dan Ackroyd wrote:
>
> On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
>
> > Methods and functions have searchable and clickable names. Operators don't.
> > The "searchable" applies to grep searches in code, but also google
>
> That's one of the reasons why I
On Thu, 16 Dec 2021 at 08:24, Pierre wrote:
>
>
> If the names are a problem, why not registering those using an attribute
> ?
If there is a strong reason to use attributes, then the argument
should start from there.
Starting from "well we could just use an attribute" and then putting
the
On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
> Methods and functions have searchable and clickable names. Operators don't.
> The "searchable" applies to grep searches in code, but also google
That's one of the reasons why I prefer a magic methods based approach.
function __plus(...){}
Hello internals,
some concerns I have about operator overloading.
(I have seen and played with operator overloading long time ago in
C++, this is my background for these points.)
1. Searchable names.
Methods and functions have searchable and clickable names. Operators don't.
The
Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :
This is not a use case I highlighted because it's one that would be
difficult to support with this RFC. But as you say, it could be a good
future expansion. In particular, putting a query builder object into core
with some more advanced overloads
On Wed, Dec 15, 2021 at 7:04 AM Dik Takken wrote:
> Hi Jordan,
>
> Thanks a lot for your work on this RFC! I like the direction this is going.
>
> One thing that may be worthwhile looking into is the query builder use
> case. I mentioned it before:
>
> https://externals.io/message/115648#115771
On Wed, Dec 15, 2021, at 10:10 AM, Rowan Tommins wrote:
> On 15/12/2021 15:03, Dik Takken wrote:
>> $query->where(Price < 100);
>>
>> Here Price is a class that represents a database column which has a
>> (static) overload of the '<' operator. The operator overload yields an
>> object
On 15/12/2021 15:03, Dik Takken wrote:
$query->where(Price < 100);
Here Price is a class that represents a database column which has a
(static) overload of the '<' operator. The operator overload yields an
object representing a database expression, which gets passed to the
where() method.
On 09-12-2021 21:11, Jordan LeDoux wrote:
Hello internals,
I last brought this RFC up for discussion in August, and there was
certainly interesting discussion. Since then there have been many
improvements, and I'd like to re-open discussion on this RFC. I mentioned
in the first email to the
Hi!
3. I am already aware of several people within internals that believe any
version of this feature will result in uncontrolled chaos in PHP codebases.
I think this is false, as I do not see that kind of uncontrolled chaos in
the languages which do have this feature. However I would think
Danack wrote:
> btw, I don't really care about this naming problem. My concern is that
> it's being used as a reason for introducing a special new type
> function, when it's really not a big enough problem to deserve making
> the language have special new syntax.
>
>
Danack wrote:
> I think
On 12/12/2021 22:01, Larry Garfield wrote:
If the list of operators is expanded by the engine, yes. The point is that IF
it were decided in the future to allow user-space defined operators, that would
be considerably easier with a separate keyword.
A real-life example of this approach
On Sun, Dec 12, 2021, at 12:56 PM, Dan Ackroyd wrote:
> On Sat, 11 Dec 2021 at 17:46, Larry Garfield wrote:
>>
>> Using symbols, however, would (with some future extension to make it
>> extensible) allow for:
>
> I don't get how it's easier, other than being able to skip naming the
> symbol
On Sat, 11 Dec 2021 at 19:13, Jordan LeDoux wrote:
>
> I *think* that all of the things you mentioned will need similar
> updates to work correctly with this RFC even if it was done
> with plain old magic methods instead.
No, that's not true. Codesniffer and all the other tools parse magic
On 12/12/2021 18:29, Rowan Tommins wrote:
Perhaps we could use an Attribute to bind the operator to the method, which
would also reduce the impact on tools that need to parse class definitions:
class Collection{ #[Operator('+')]
public function union(Collection$other,
On Sat, 11 Dec 2021 at 17:46, Larry Garfield wrote:
>
> Using symbols, however, would (with some future extension to make it
> extensible) allow for:
I don't get how it's easier, other than being able to skip naming the
symbol name. e.g. adding union and intersection operators
function
On Sun, 12 Dec 2021 at 08:55, James Titcumb wrote:
>
> The only mitigation for unnecessary complexity I can think of is to force
> overloaded operators to be "arrow functions" to encourage only minimal
> code, e.g.
>
The 'valid' use-cases for this aren't going to minimal pieces of code.
Things
On 12/12/2021 17:32, Larry Garfield wrote:
The only mitigation for unnecessary complexity I can think of is to force
overloaded operators to be "arrow functions" to encourage only minimal
code, e.g.
operator +(Number $other, OperandPosition $operandPos): Number => return
new Number
On Sun, Dec 12, 2021, at 2:55 AM, James Titcumb wrote:
> On Thu, 9 Dec 2021, 20:12 Jordan LeDoux, wrote:
>
>>
>> RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads
>
>
> I'm not strongly opinionated on either approach (magic __add vs operator +)
> although I have a very slight
On Thu, 9 Dec 2021, 20:12 Jordan LeDoux, wrote:
>
> RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads
I'm not strongly opinionated on either approach (magic __add vs operator +)
although I have a very slight preference to your propose operator + syntax,
however despite very
On Sat, Dec 11, 2021 at 7:15 AM Dan Ackroyd wrote:
>
> There are quite a few downstream costs for making a new type of
> methods in classes. All projects that analyze code (rector,
> codesniffer, PHPStorm, PhpStan/Psalm, PHPUnit's code coverage
> annotations etc) would have to add a non-trivial
On Sat, Dec 11, 2021, at 9:15 AM, Dan Ackroyd wrote:
> Hi Jordan,
>
> On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux wrote:
>>
>> Hello internals,
>>
>> I last brought this RFC up for discussion in August, and there was
>> certainly interesting discussion. Since then there have been many
>>
Hi Jordan,
On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux wrote:
>
> Hello internals,
>
> I last brought this RFC up for discussion in August, and there was
> certainly interesting discussion. Since then there have been many
> improvements, and I'd like to re-open discussion on this RFC.
In general
Hello internals,
I last brought this RFC up for discussion in August, and there was
certainly interesting discussion. Since then there have been many
improvements, and I'd like to re-open discussion on this RFC. I mentioned
in the first email to the list that I was planning on taking a while
44 matches
Mail list logo
