[Note: I've included the full text of the previous message as it wasn't
sent to the list.]
On 17/11/2019 18:35, Aimeos | Norbert Sendetzky wrote:
It feels like there are two alternative suggestions here. Not only do
they use the same keyword to mean different things, but "convertible to
array", and "usable as array" seem like distinct concepts to me.
The name of the interface isn't perfect because it may be too close to
the type hint and therefore misleading. Suggestions for a better name
are always welcome.
The concept contains three parts:
- arrayable type hint: Use objects and arrays alike
- \Arrayable interface: To enable implementing objects that are "arrayable"
- __toArray(): To convert objects to arrays
Like I say, the name is part of it, but the purposes also overlap the
way you describe them. It makes more sense to me to have two separate
features for two separate use cases:
- If I just want to know that the object I've received can be iterated,
counted, and accessed using square brackets, then I need either a
special type hint or a new interface, but not both.
- On the other hand, if I just want to know I can call toArray or
__toArray on an object, I don't care whether it implements Iterator,
Countable, etc as well.
For the "convertible to array" case, I think __toArray, or an interface
specifying just that one method, would make more sense than combining it
with the existing interfaces. I'm sceptical of that concept, though,
because most objects could be converted to many different arrays in
different circumstances, each of which should be given a different and
descriptive name.
Can you give some examples for different conversions?
Well, pretty much any method that returns array *could* be called "to
array", but not many would be good candidates for such a generic name.
You might return an array structure to be incorporated into a JSON
response, or to be passed to a template renderer, or to map to database
columns, etc.
The only case I can think of where a generic "toArray" method would make
sense is if you're creating a general-purpose "collection" or "list"
object, in which case you're probably better off directly implementing
methods like map and sort, rather than encouraging users to convert it
back to a plain array. It doesn't seem like a common enough use case to
need a new language feature, when it's simple enough to write
"$foo->toArray()" without anything new.
The possibility to pass arrayable objects to the array_* methods should
be out of scope for the moment and is better discussed later to keep the
pieces small, I think. You are totally right, there may be some
unexpected behavior when doing that.
The reason I mentioned it is that without it the new type hint or
interface seems rather limited: I can't imagine many "array" type
constraints being replaced with "arrayable" if you had to remember not
to pass the variable to array_map, sort, etc.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
