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 you've
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 would
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 name.
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
method
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, OperandPosition$ope
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 __union(
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 l
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 ($this->value
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 pref
I already added a new function `array_group`, any further
comments/thoughts will be highly appreciated.
Regards,
~Hassan
On Wed, Dec 8, 2021 at 11:35 AM Hassan Ahmed <7sno...@gmail.com> wrote:
>
> Hendra Gunawan IMHO your suggestions is not related to
> `array_group()`, you are talking about a gr
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 occ
11 matches
Mail list logo
