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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
