On Mon, 18 Nov 2019 at 17:55, Mike Schinkel <m...@newclarity.net> wrote:
> > Yes, a team lead could require an interface be used for consistency across > a team, which is fine, but it is not consistent across unrelated projects. > Having worked with GoLang for a while where interfaces are not required to > be explicitly named by classes that implement them I have learned that > having consistency across unrelated projects can result in some > surprisingly serendipitous reuse scenarios. > > That's actually precisely why I *don't* like generic names like __toArray(). How do I know looking at it whether this particular method will give me something suitable for passing to a Mustache template, or just a list of IDs used in some cross-referencing algorithm? The only thing I know from the name is "it returns an array". > Forgive me for saying, but that argument is bordering on reductio > ad absurdum. We are talking about a magic method for converting to a > *built-in *data type. > > ... > That said, I could see a value in having __toInt(), __toFloat(), and > __toBool() as having them would allow us to represent scalar data types > in classes. That could be extremely useful in selected contexts. > > So given the argument there would at maximum be five (5) new magic methods > that could be added vs. the infinite methods you assert this approach would > invite. > > I didn't say it would *invite* infinite methods, I said it would only give the claimed benefits if you had a huge number of magic / "standard" methods, because you need to "standardise" every method you have in your current code base. __toBool() is perhaps a good comparison. Would you consider renaming a method called "isSuccessful()" to "__toBool()" a positive change? Because I would not. If there is a common requirement for objects to be converted to a > particular type of array, then you should pick a standard name for that > > > You assert that a developer *"should"* do it the way you believe is > correct, but what is the arbiter of *"should"* vs. *"should not"* here? > Is there some fundamental best practice that the industry has universally > embraced that I am unfamiliar with, or just your opinion? > > Are you saying that you *don't* believe consistency is a good thing? Because that's all this sentence really says: "if you have something you do a lot, you should do it in a consistent way". The justification for that can be found in the introduction to any style guide you can lay your hands on. > Absolutely agree that names need to be meaningful, which is why I want > more control, not less. > > What you are implicitly saying is that rather than allow others the option > to use __toArray() which by its nature could result in consistent use > across unrelated projects you want to deny others who value it from being > able to take advantage of it because you personally do not see value in it > and would not use it. Or did I misrepresent? > > I think you are misrepresenting slightly. I haven't actually said I want to "deny" or "block" this addition. What I have said is that I am unconvinced by the arguments being put forward in favour of it, and have tried to point out what I see as flaws in those arguments. In particular, if your claim is that it will make code more consistent across code bases, it's no use if you're the only person that adopts it. So let me rephrase from a personal objection to a prediction: I predict that people will not use this feature consistently in a way that will bring the benefits you claim for it. > So I now understand that you were proposing even less than I thought you > were proposing. I thought you were proposing that PHP would recognize and > give speaking meaning to a method called toArray() or similar. Now I > realize you were proposing even less and instead placing the burden of said > standardization on each project, guaranteeing no serendipitous reuse across > projects. :-( > > There is certainly benefit to standardising things across projects, and that's what organisations like PHP-FIG try to do. However, standardisation is more useful the more specific it is, and if the definition of "toArray" is just "it returns an array that in some way represents the object", I'm struggling to see how that would lead to useful interoperability. > But it is reasonable to expect that a class could need both an __invoke() > and a __toArray() method. > > It's also reasonable to expect that a class could need two methods that return arrays; you've already "solved" that, by splitting the methods among more classes and namespaces so they don't need unique names any more. > Also there is no guarantee that an object that implements __invoke() will > return an array whereas there should be a reasonable guarantee that if > function_exists($object,'__toArray') is true that casting to (array) > would be valid. > > Which brings us back to square one: knowing that a method returns an array isn't enough; I need to know what kind of array that is, and the thing that normally tells me that is the method's name. Regards, -- Rowan Tommins [IMSoP]
