Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90092 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85191 invoked from network); 5 Jan 2016 14:29:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jan 2016 14:29:59 -0000 Authentication-Results: pb1.pair.com header.from=lisachenko.it@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lisachenko.it@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender) X-PHP-List-Original-Sender: lisachenko.it@gmail.com X-Host-Fingerprint: 209.85.217.177 mail-lb0-f177.google.com Received: from [209.85.217.177] ([209.85.217.177:34510] helo=mail-lb0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 29/21-12097-563DB865 for ; Tue, 05 Jan 2016 09:29:59 -0500 Received: by mail-lb0-f177.google.com with SMTP id pv2so190878981lbb.1 for ; Tue, 05 Jan 2016 06:29:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K0NXUhxGx0a5v1Grh1YTKf9la7H2KCof6IP+MgwTxOM=; b=VKuSIiFMgk53py1bj9GYy9ssO790DAFRlhe4nuqcslboCwb6m+dK+Qm/GNRCphU2s8 dtQWPTQRL/JAf2sqFLJxJmIq/EvOUvYfNZ1xJF0p0ohpF15HnKX12ZkK4tJ1Le7UoUo3 zmDSOE1kRCZDsYW4jfz+mvJ+otvMFLcxKga73ifCf5gmqSGzwEcfItZjXX7C7OxGPdeD wMy4BwnwcWULZ/6ds0WrUu/lYrGV8qecIGEsdPPtBvl8kuniCZJKMpa4A+VrLANECAdJ LVtHMzmQhJvanM1WUOUp1XKOGjp7jv8knjzHjSDav15JgdiS13V6FflO8MUY2g4xATi0 3sow== MIME-Version: 1.0 X-Received: by 10.112.199.105 with SMTP id jj9mr32282545lbc.131.1452004194675; Tue, 05 Jan 2016 06:29:54 -0800 (PST) Received: by 10.25.160.71 with HTTP; Tue, 5 Jan 2016 06:29:54 -0800 (PST) In-Reply-To: <68.B0.07292.98AFA865@pb1.pair.com> References: <12.34.07292.41F9A865@pb1.pair.com> <568AF408.6020105@gmail.com> <68.B0.07292.98AFA865@pb1.pair.com> Date: Tue, 5 Jan 2016 17:29:54 +0300 Message-ID: To: Andrea Faulds Cc: PHP internals list Content-Type: multipart/alternative; boundary=001a11c3462a3c789c0528971222 Subject: Re: [PHP-DEV] Re: RFC Operator Overloading in Userspace From: lisachenko.it@gmail.com (Alexander Lisachenko) --001a11c3462a3c789c0528971222 Content-Type: text/plain; charset=UTF-8 2016-01-05 2:04 GMT+03:00 Andrea Faulds : > I agree that we could do something with interfaces. I would like to point > out that we actually already have an example of this, in the form of the > \ArrayAccess interface, which requires you to implement all the different > indexing operations at once. Unfortunately, though, \ArrayAccess doesn't > give us a precedent for dealing with the $this issue (in `$a + $b`, who > gets called, how do we handle differing types, etc?), but it's a start. > Hi, Andrea and internals team! Interface is a good way to implement new functionality for classes, but operator overloading is language feature itself, so from my point of view, it will be better to put this functionality into the magic method. Personally, I don't like hundreds of __add, __mul, __etc methods, because this will be ugly and will require addition of new methods when new operators are included (eg __pow). I want to suggest to add only one single method: public function __operator(int $operatorKind, ...$operatorArgs); This method will be called for every operator and class can check the $operatorKind variable with simple check: if (Php\Operator::OP_DIVISION === $operatorKind) return $operatorArgs[0]->value / $operatorArgs[1]->value; New values for operator type enumeration can be added later into new versions of PHP easily. --001a11c3462a3c789c0528971222--