Re: [RFC] User Defined Operator Overloads (v0.6)

From: Date: Sun, 12 Dec 2021 18:56:32 +0000
Subject: Re: [RFC] User Defined Operator Overloads (v0.6)
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-116628@lists.php.net to get a copy of this message
On Sat, 11 Dec 2021 at 17:46, Larry Garfield <larry@garfieldtech.com> 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(...){} function __intersection(...){} vs operator ∪(...){} operator ∩(...){} In fact, I find one of those quite a bit easier to read... Larry Garfield wrote: > It uses effectively the same operator sigil, though. Yes, that's what I was trying to say. Danack wrote: > The name of the function (e.g. __add) always refers to the symbol used > where it is used, not what it is doing. If the naming is taken from the sigil, then it's always appropriate. So if operator * has the magic method __asterisk instead of __mul, it avoids any suggestion of what the operation actually means for the object. 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. cheers Dan Ack

« previous php.internals (#116628) next »