On Mon, 13 May 2019 at 14:46, Steven Wade <stevenwad...@gmail.com> wrote:
> > Hi all, I wanted to re-ping the list to see if there is any more feedback > on this proposal? Any technical concerns or true BC changes? > I'm personally unconvinced of the value of this, and would probably propose it was blocked by coding standards in my team if it was added, because its meaning is so ambiguous. I actually see quite a lot of classes with normal methods called things like "toArray", and my comment is always "to *what* array?" Most objects do not have a single "natural"/"canonical" array representation, and such a transform is usually actually used as part of some particular helper or code pattern - e.g. an intermediate form for serializing to XML/JSON, or a compatibility-wrapper for legacy code. There's nearly always a better name for the method that properly indicates its intent. As a thought experiment, imagine a similar method which allowed you to overload (object)$foo. Although (array)$foo tells you slightly more than that, I'm not convinced it tells you enough that you're not just hiding meaning behind cute syntax. JsonSerializable actually suffers from similar problems, and is IMO useful only because it's automatically recursive. I presume the proposed mechanism would not be, i.e. return [$foo] would not be interpreted as return [(array)$foo]. Regards, -- Rowan Collins [IMSoP]
