On 01/04/2016 05:04 PM, Andrea Faulds wrote:
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.
As a non-Haskell-knowing dev I only followed a portion of the
conversation leading up to this, but I think I'm tentatively liking the
direction this is moving. If I understand correctly, the suggestion is
to add, eventually, e.g.:
interface Comparable {
public function compare($other) : int; (returns -1, 0, 1)
}
interface ArithmeticStuff {
public function add($other) : ArithmeticStuff;
public function subtract($other) : ArithmeticStuff;
// ...
}
Am I following?
If so, I see the following (possibly surmountable) concerns:
1) The ArithmeticStuff interface (obviously better named) still has no
way to prevent mutation of $this or $other. I still see that as
user-space trainwreck waiting to happen unless there's some way to force
those methods to NOT modify $this in any way.
2) Besides the issue with different classes that both implement the same
operator interface, as Andrea notes, it also would cause issues with
subclasses. To wit:
class Money implements Numberish {
protected $valueWithoutDecimals;
public function add($other) {
$ret = new Money($this->valueWithoutDecimals);
$ret->valueWIthoutDecimals += $other->valueWithoutDecmials;
return $ret;
}
}
class Dollars extends Money {}
$d1 = new Dollars(4);
$d2 = new Dollars(5);
$d3 = $d1 + $d2;
$d3 would now be an instance of Money, NOT Dollars. Sure, there are
better ways of writing that implementation that would avoid that problem
(cloning $this, using get_called_class(), etc.) but that the potential
is there is worrisome.
Possible solution to 1 and 2: Instead of just passing $other, pass
$clone and $other, and block $this. To wit:
class Money implements Numberish {
protected $valueWithoutDecimals;
// Being static, $this doesn't exist although it's what $clone was
cloned from.
public static function add($clone, $other) {
$clone->valueWIthoutDecimals += $other->valueWithoutDecmials;
return $clone;
}
}
That way, the engine pre-clones $this for me, and I operate from that.
I could ignore $clone if I wanted to, but I cannot ever modify $this.
(That wouldn't address the mixed class question entirely, but does
address forced-immutability.)
3) A long-standing source of aggravation for user-space devs is that
it's impossible to build an object that is a for-reals replacement for
arrays. We can implement ArrayAccess, Countable, Iterator, whatever,
but for all practical purposes they're still not even remotely close to
being arrays as far as the type system or array functions are concerned.
If what we're talking about here is adding more "act like a primitive"
interfaces for objects, we need to think through all of those little
nuances to make them as non-annoying as possible. (Eg, would an integer
pass a Numberish type check? In weak mode or strict mode? Can I pass a
Numberish to strpos()? Can I pass a Stringish to strpos()?) I don't
have answers for those but I would hope we'd think those through to
avoid the split existence that is collections/arrays.
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.
An example of a user-space string object is in Drupal 8: We added (very
late) a TranslatableString class, which contains a string template (with
placeholders), the placeholder replacements, and various cache-related
metadata. Off hand, I don't know if adding a Stringish interface to
that would be good or terrible. :-) It needs to be compiled into an
actual string (replacing the template with an alternate version for
another language if appropriate) during rendering so that we have the
right cache information available, a process that requires external
services. Off hand I have no idea what adding a concat() method or
position()/ArrayAccess method to that would do or if it would eat our
kittens, but I mention it here as another example in the wild.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
