Re: Concept: "arrayable" pseudo type and \Arrayable interface

> On Nov 17, 2019, at 6:51 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > I'm not sure avoiding the name "toArray" necessarily leads to "really long > method names" - even with extremely specific distinctions, you don't need to call the > method "toJsonArrayForVersion5OfTheApi", just "toV5Json" or > "getV5Array" or "formatForJsonV5". I now realize that my commenting on my experience in reviewing legacy code — where long names are frequently used, regardless of the fact they are not required — caused you to focus on the long naming comment aside and not on the primary ask for consistency. Even if short, a code base littered with method names like toV5Json() or getV5Array() or formatForJsonV5() is still inconsistent. > The important thing is that the method name is now communicating its *purpose*, whereas > "toArray" communicates only its return type, and a hugely flexible return type at that. What I was suggesting instead, which obviously was not clear, is that you communicate the *purpose* with the namespace and by doing so allows for the capability of casting to array be added. Otherwise the perfect is the enemy of the good. > I'm not clear what these objects represent. If I have a Widget object passed out from some > business logic, Similarly it is not clear to me was toV5Json() or getV5Array() or formatForJsonV5() mean. However if V5 somehow has meaning then your namespaces class could just as easily be named if that is what you want: \Widgets\ToV5Json\Widget > how do I make use of these other classes? Would I have to call "(array)(new > \Widgets\Mustache\Widget($myWidget))", as sugar for "(new > \Widgets\Mustache\Widget($myWidget))->__toArray()"? Maybe we code differently, but I would never write a full namespace in code like that. I would have one of the following at the top of my PHP file: use \Widgets\Mustache\Widget use \Widgets\Mustache\Widget AS MustacheWidget That would result in the following as one of — a you say — sugar for (new \Widgets\Mustache\Widget($myWidget))->__toArray(): (array)(new Widget($myWidget)) (array)(new MustacheWidget($myWidget)) However I doubt I would ever instantiate and then cast the object in the same line of code. Instead the value of array casting — to me — is in its polymorphic nature where I can have a "generic" method that can just cast to an array and instead of having to know if the developer used toV5Json() or getV5Array() or formatForJsonV5(). > If so, I don't really see the benefit of the magic method over just standardising a method > name, like "interface MustacheFormatter { public function getData(): array; }" Backward compatibility is the benefit. If we standardize one any name then we can break existing code. Adding a magic method cannot break existing code unless that code violated the reserved nature of double underscore methods. Or are you proposing we start adding __*() methods that are not actually magic? > Which is basically my objection to __toArray() - I can't think of many situations where > writing (array)$foo saves or gains you anything over writing $foo->asArray() or > $foo->somethingMoreSpecific() But I and others can think of situations where it would help. Because asArray() and somethingMoreSpecific() are neither a standard you don't get polymorphism with different named methods. And any new standard non-magic method we add has the potential to break BC. And is unlike anything else in PHP I can think of. OTOH, I have a hard time thinking of a scenario where __toArray() would actually cause a problem for someone like you who cannot think of a benefit. Can you present a use-case how it would cause you a tangible problem that could not be resolved with namespaces or by just creating your own somethingMoreSpecific() method and ignoring __toArray()? -Mike