Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90015 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 833 invoked from network); 4 Jan 2016 23:04:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2016 23:04:42 -0000 X-Host-Fingerprint: 2.218.134.247 unknown Received: from [2.218.134.247] ([2.218.134.247:21862] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/B0-07292-98AFA865 for ; Mon, 04 Jan 2016 18:04:42 -0500 Message-ID: <68.B0.07292.98AFA865@pb1.pair.com> To: internals@lists.php.net References: <12.34.07292.41F9A865@pb1.pair.com> <568AF408.6020105@gmail.com> Date: Mon, 4 Jan 2016 23:04:37 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <568AF408.6020105@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 2.218.134.247 Subject: Re: [PHP-DEV] Re: RFC Operator Overloading in Userspace From: ajf@ajf.me (Andrea Faulds) Hi Stas, Stanislav Malyshev wrote: > Hi! > >> constraint on function parameters and return types. I think it would be >> more worth pursuing a Haskell-style approach in PHP, most likely with a >> hierarchy of magic interfaces. > > I agree that interface approach looks better than Python/C++ approach > for PHP. One thing it also allows is introducing things in a gradual and > conceptually sound manner - i.e. Comparable, Numeric, etc. which would > implement specific operator set instead of just letting people > implementing random bag of operators. I'm not sure how to make it > technically but it looks better to me conceptually. We don't have as > powerful type system as Haskell but I think we still can do a lot with > interfaces. 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. >> should work on all number types. I don't think GMP currently overloads >> any of these, though, and there is the possibility we might create >> confusion if overloading extended to math functions. > > Which reinforces the point above that maybe before the are tackling the > operators in userspace we need to identify use cases and create > structure for them, and then it might be easier for us to avoid > inconsistencies. We're kind of moved forward with GMP without doing > that, but fortunately it's easier to fix such things while it's confined > to the engine/extensions. Once it's in userspace, changing it would be > way harder. In full agreement there. On that note, it's of course possible to support overloading certain things, but only internally. It might be reasonable to expose __assign_add (well, its C equivalent) to GMP but not to userland, for instance. Regarding use cases, there are a few that come to mind. One of these is userland number types. We don't, to the best of my knowledge, currently have a decimal type as a PHP extension, so applications which need it must look to userland implementations (often backed by bcmath underneath). These would be more pleasant and intuitive to use if they could use our normal arithmetic operators. For such userland types, I imagine an interface with basic arithmetic operations would work. Perhaps we might call it \Number. A question might be whether to split apart integer and float operations like Haskell does. I'm not sure what fits this use-case best, though it's probably better not to require classes to implement what they don't need, and just let people get an error if they do, say, ($decimal % 5). Another use case is userland string types. There's several projects out there which wrap PHP strings in an object to provide an object-oriented interface which is more pleasant to use than PHP's string API. There is also the use-case of Unicode string wrappers, since PHP still doesn't have a Unicode string type. They would benefit from being able to overload the concatenation operator, and possibly also the binary operations (^, & and |) which work on strings. Everything else these types need is already overloadable with the existing \ArrayAccess and \Iterator(Aggregate). There is a problem here, through, in what we should require such classes to implement beyond concatenation. Requiring nothing else leaves it open to abuse (I can already imagine `.` being used for the dot product), but requiring, say, binary operations would be unfair (they're nonsense in the context of Unicode), as would \ArrayAccess (Unicode strings may have non-constant time indexing) or \Traversable (a Unicode string class might choose to lack a default iterator to force the user to consider the different ways a Unicode string can be used). Maybe we could require \Countable, but even that has problems regarding Unicode, non-constant time complexity especially. So, I'm not quite sure what to do there. Thanks. -- Andrea Faulds https://ajf.me/