Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116634
Message-ID: <a8a802a5-4f84-5dd4-2f8f-8c14bac6958d@gmail.com>
Date: Mon, 13 Dec 2021 00:01:50 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Firefox/91.0 Thunderbird/91.3.2
Content-Language: en-US
To: internals@lists.php.net
References: <CAMrTa2FB-EVGq29oLCU8fYkMYi+KsQiEAFv1xxMFO7vnm8e6=Q@mail.gmail.com>
 <CA+kxMuQqGpkuqwFLrW29G38aOUNbvXM6Dq=P8NXt=1zai_=zxA@mail.gmail.com>
 <7126a5cb-fdaf-4e50-b8af-7d95965d1125@www.fastmail.com>
 <CA+kxMuROkHkVVWd0AFDweQBBNqXCkPmGqJVggGduDF6=KyZEgg@mail.gmail.com>
 <CAMrTa2Gkra=yA9x+C6mLCTmGSkxn__PCzAwsBxO9Uyk2meXocA@mail.gmail.com>
In-Reply-To: <CAMrTa2Gkra=yA9x+C6mLCTmGSkxn__PCzAwsBxO9Uyk2meXocA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)
From: smalyshev@gmail.com (Stanislav Malyshev)

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 that
> allowing arbitrary overloads would increase that proportion.

Depends on how you define "uncontrolled chaos". I have encountered 
toolkits where the authors think it's cute to define "+" to mean 
something that has nothing to do with mathematical addition (go read the 
manual for an hour to figure what it actually does) or for += to mean 
something different than + and assignment. Some people even learn to 
love it, so far I haven't.

> However, once a feature is added it is very difficult to change it. Not
> only for backward compatibility reasons, but for the sheer inertia of the
> massive impact that PHP has. I do not plan on ever proposing that arbitrary
> symbol combinations be allowed for overloads myself. But I cannot possibly
> know what internals might think of that possibility 10 years from now when
> this feature has been in widespread usage for a long time. Using magic
> methods makes it extremely difficult at *any* point in the future to allow
> PHP developers the option of an overload for say +=+. What would such a

That's awesome. The only thing worse than a toolkit author that thinks 
it's cute to play with "+" is the one that thinks it's cute to invent 
some random combination of special characters and assign it some meaning 
that of course is obvious to the author, but unfortunately that's the 
only person in existence to whom is it obvious. Some people enjoy the 
code being a puzzle that you need to untangle and make a sherlockian 
detective work to even begin to understand what is going on in this 
code. Other people have work to do. And again, what's the intuitive 
difference between operators +=+@-+ and ++--=!* ?

Of course, of course I know, every feature can be abused. The difference 
here is that if it's hard to think about any use that wouldn't be an abuse.

> That sounds far *less* maintainable to me. It seems more likely that even
> if it were a desired feature 10 years from now, it would be something that
> would be extremely difficult to implement, maintain, and pass.

I must notice "if" carries a lot of load here.
-- 
Stas Malyshev
smalyshev@gmail.com