Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition

Mailing Lists php.internals
1

Hi,

Hello internals,

I've updated the RFC to include final-ish examples (barring any further constructive feedback), a prototype implementation, and an objections section.

Cheers,

Rob

It seems like the "hack" I mentioned is still possible, am I misunderstanding something?

And I don't understand the purpose of polyfills at all. If you're not using the GMP extensions and can't do operator overloading, won't you just have a class with protected methods that are never used and don't actually do anything?

Regards,

Saki

2

On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote:

Hi,

Hello internals,

I’ve updated the RFC to include final-ish examples (barring any further constructive feedback), a prototype implementation, and an objections section.

Cheers,

Rob

It seems like the “hack” I mentioned is still possible, am I misunderstanding something?

That’s always going to be a possibility, no matter what we do or how we do it. I think it would be a rather pointless hack now that I can run the code. For the most part, the engine treats these as numbers and trying to dodge that will land you in hot water eventually.

And I don’t understand the purpose of polyfills at all. If you’re not using the GMP extensions and can’t do operator overloading, won’t you just have a class with protected methods that are never used and don’t actually do anything?

Ah, that could probably be clearer in the RFC, but you have to make it public to be able to use it.

It’s a bit clunky to use without the extension, but that’s mostly because I didn’t want to get into OperandPosition from Jordan’s RFC. Many people were confused about it, so I’m just avoiding it.

— Rob

3

On Sun, Jun 30, 2024, at 06:59, Rob Landers wrote:

On Sun, Jun 30, 2024, at 01:28, Saki Takamachi wrote:

Hi,

Hello internals,

I’ve updated the RFC to include final-ish examples (barring any further constructive feedback), a prototype implementation, and an objections section.

Cheers,

Rob

It seems like the “hack” I mentioned is still possible, am I misunderstanding something?

That’s always going to be a possibility, no matter what we do or how we do it. I think it would be a rather pointless hack now that I can run the code. For the most part, the engine treats these as numbers and trying to dodge that will land you in hot water eventually.

After playing with the code and seeing what I could get away with, making the GMP class readonly appears to prevent many abuses, so I have amended the RFC and prototype code.

And I don’t understand the purpose of polyfills at all. If you’re not using the GMP extensions and can’t do operator overloading, won’t you just have a class with protected methods that are never used and don’t actually do anything?

Ah, that could probably be clearer in the RFC, but you have to make it public to be able to use it.

I’ve iterated it a few times in the text of the RFC.

— Rob

4

Hi,

It seems like the "hack" I mentioned is still possible, am I misunderstanding something?

That’s always going to be a possibility, no matter what we do or how we do it. I think it would be a rather pointless hack now that I can run the code. For the most part, the engine treats these as numbers and trying to dodge that will land you in hot water eventually.

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.

And I don't understand the purpose of polyfills at all. If you're not using the GMP extensions and can't do operator overloading, won't you just have a class with protected methods that are never used and don't actually do anything?

Ah, that could probably be clearer in the RFC, but you have to make it public to be able to use it.

It’s a bit clunky to use without the extension, but that’s mostly because I didn’t want to get into OperandPosition from Jordan’s RFC. Many people were confused about it, so I’m just avoiding it.

This is very confusing me. Why does this need to be a child class of GMP?

Regards,

Saki

5

On Sun, Jun 30, 2024, at 09:31, Saki Takamachi wrote:

Hi,

It seems like the “hack” I mentioned is still possible, am I misunderstanding something?

That’s always going to be a possibility, no matter what we do or how we do it. I think it would be a rather pointless hack now that I can run the code. For the most part, the engine treats these as numbers and trying to dodge that will land you in hot water eventually.

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.

And I don’t understand the purpose of polyfills at all. If you’re not using the GMP extensions and can’t do operator overloading, won’t you just have a class with protected methods that are never used and don’t actually do anything?

Ah, that could probably be clearer in the RFC, but you have to make it public to be able to use it.

It’s a bit clunky to use without the extension, but that’s mostly because I didn’t want to get into OperandPosition from Jordan’s RFC. Many people were confused about it, so I’m just avoiding it.

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!

— Rob

6

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.

Again, if such functionality is provided, it should be exposed as formal support for operator overloading.

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?

Regards,

Saki

7

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

8

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

9

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

10

After some consideration and lack of enthusiasm; I’m withdrawing this RFC.

— Rob