On Sun, Jun 30, 2024, at 13:37, Saki Takamachi wrote:
>
> Hi,
>
>> On Sun, Jun 30, 2024, at 13:05, Saki Takamachi wrote:
>>>
>>> Hi,
>>>
>>>>> I'm not sure. Does this mean that such "hack" is unavoidable?
>>>>>
>>>>> And I don't really understand what "pointless hack" means. This
>>>>> would make sense if operator overloading was already allowed, but it isn't.
>>>>
>>>> Not unavoidable, but pointless. For example, I attempted to create a String class
>>>> that used + for concatenation. This kinda works, but if you pass it to something that takes a
>>>> string, you get the underlying number and not the string you were trying to store. This is because
>>>> GMP takes over casting forcing you to stick to numerical constructs.
>>>
>>> I don't understand why you only consider the casting case. You can simply convert
>>> it to a string via a method. As long as don't use any casting at the end, users can implement
>>> it however they like. I don't think this is a pointless hack.
>>>
>>> Also, allowing "hack" just because they're not useful is not a good
>>> idea.
>>
>> We could just delete php-src, grab a beer, and watch the sunset. I don’t think you’ll
>> ever be able to stop some programmers from hacking things together to solve business problems
>> though. I’ve “hacked” weakmaps in userland to make Hour(1) === (yes, there are three! Equals
>> there) Minute(60).
>>
>>>
>>> Again, if such functionality is provided, it should be exposed as formal support for
>>> operator overloading.
>>
>> Thank you for your opinion, this RFC doesn’t stop that from happening and is completely
>> orthogonal.
>>
>>>
>>>>> This is very confusing me. Why does this need to be a child class of GMP?
>>>>
>>>> This is addressed in the current RFC text, if I missed something, please ask!
>>>
>>> I don't understand why the GMP RFC mentions environments where GMP is not used.
>>>
>>> There are a few other points worth mentioning, but the existence of polyfills makes
>>> this especially confusing.
>>>
>>> > To be usable, the developer must override the desired operations and make them
>>> > public
>>>
>>> Is this referring to a polyfill? Or is this just a necessary step to override the
>>> overload?
>>
>> I recommend reading up on what a polyfill is, and why they are useful, if you are confused.
>> But to answer your question, no, it has nothing to do with the polyfill, it’s just a necessary
>> step. The polyfill is just provided for completeness.
>>
>>>
>>> Regards,
>>>
>>> Saki
>>
>> — Rob
>
> I understand your point, and any further comment from me would probably be of little value to
> you. This will be my last post on this thread.
>
> I will definitely vote against this RFC unless the issues I have pointed out are addressed. No
> matter how innocuous they may seem, I would rather not expose operator overloading in the form of
> such "hack".
>
> Regards,
>
> Saki
Thanks, I would love to address your issues but you’ve given me nothing actionable to work with.
Thank you for your time.
— Rob