> On Nov 17, 2019, at 6:51 PM, Rowan Tommins <[email protected]> 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
