Re: Operator overloading for userspace objects
| From: | Rowan Tommins | Date: | Sat, 08 Feb 2020 20:18:09 +0000 |
| Subject: | Re: Operator overloading for userspace objects | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108426@lists.php.net to get a copy of this message | ||
On 06/02/2020 20:06, Andrea Faulds wrote:
Haskell has a nice approach (probably some other languages have this too) where it has typeclasses that contain related operators, which means that e.g. if you want to overload +, your type needs to support Num which also contains -, *, abs, the sign function, and conversion from integers. [...] Also, Haskell also lets you just define arbitrary operators, which may even look the same as the built-in ones if you really want to, so maybe it's a bad comparison point :pIt's interesting that in this sense, Haskell supports *both* of the "philosophies" of overloading that I mentioned in my last message. [1] I guess they're intended for different "levels" of programming in a sense: - From what I've heard Haskell tries to make as little distinction between "built-in" and "user-defined" as possible, so like Postgres, the actual "normal" definitions of the operators need to be defined by some low-level language feature. - On the other hand, that low-level feature is used to build a standard higher-level language, and that high-level language treats types as more important than symbols. In general, I think PHP is quite a high-level language, and doesn't tend to let you re-define core concepts to build new versions of the language, so the type-based approach to operator overloading feels more in keeping to me. If we had other low-level features - hygienic macros, meta-programming, meta-classes, that kind of thing - then defining new meanings for individual operator symbols would make more sense. [1] https://news-web.php.net/php.internals/108347 - not showing on https://externals.io for some reason Regards, -- Rowan Tommins (né Collins) [IMSoP]