I had to snip context and split in two to get under the 30k char limit. > On Sep 16, 2019, at 6:22 AM, Rowan Tommins <rowan.coll...@gmail.com > <mailto:rowan.coll...@gmail.com>> wrote: > > Points 1 and 3 are solved by anonymous classes, which we already have. > Point 2 is a bit vague; is your point essentially "if we had nicer syntax > for anonymous classes people would use them more"? If so, then see next > section; if not, I'd like more clarification on what you were trying to > illustrate with your "nested parameters" example.
The primary point here was: "If we had an easier syntax for object initializers, people would be more likely to use them instead of using arrays" Note I said "object initializers" not "anonymous classes" because the alternative is people using arrays. And that is one of reasons things I really want object initializers; so that developers who use arrays for structured data will be more likely to use objects instead. Myself included. > The problem with trying to make anonymous class declarations and object > initalizers look and feel similar is that there's a lot more that can go > into an anonymous class declaration: types, visibility, methods, traits, > "extends" and "implements" clauses, etc. Good point about anonymous class declarations. Frankly though, I personally (almost?) never use anonymous classes except for very simple ones because anonymous classes quickly because too complex. I find it much easier to reason about named classes at the point they need features like visibility, methods, traits, extends and implements clauses, I see object initializers as a subset of anonymous class declarations. IOW, if declaring (what I will call) ad-hoc objects get too complicated then users will stop using them for the object initialization use-case. This is premised on the fact I have usually seen less-zealous developers take the path of least resistance and arrays have been that path. A lot of the code I have seen has been in WordPress plugins — and some people on this list have made comments about them — but if the PHP community wants to see them become better then making it more likely they will choose the better path will help improve them. So if we get developers using objects instead of arrays, I think are will be more apt to recognize that they can benefit from declared named classes and move to those instead of objects. But if they are using arrays, I see no evidence that they will move to declared named classes. > I think that's a good reason not to think of them as related features, unless > you can think of use cases where having variable capturing in an > anonymous class declaration would mean you would no longer want object > initializers? That question is confusing me given the context. Was there a typo/is it worded correctly? > I'm a bit confused here whether we're talking about constructing objects of > anonymous classes, named classes, or both. Your example showed constructing > a defined Query object, but your comments above sound more like they're > about using anonymous classes (as a replacement for arrays). I understand your confusion; my fault. There are so many use-cases I have for object initializers that it is hard to stay focused on one specific use-case. And I have yet to give an example of one my primary use-cases given it's a coding pattern I might need to discuss first so it would be clear why object initializers would be so helpful. I see object initializers being what beginners devs would start with, and what advanced devs would use is very ad-hoc use-cases. As beginners become intermediate they would start using basic named classes. And when they became more advanced they would start using features like visibility, traits, extends and implements. So I envision it as a continuum, that IMO would be better if object initializers were just a simplified subset of anonymous classes rather than being an entirely different set of syntaxes to learn. > Either way, I agree with the aim of making objects easier to construct, I'm > just discussing the pros and cons of the various suggestions for doing that. +1! > As before, the definition of the class itself is simpler, but I think a > short-hand syntax for constructors would be a better compromise than a > syntax that only worked with public properties and parameterless > constructors. I think short-hand syntax for constructors would probably be a great feature oo, but do not think of them as satisfying any more than a few of the the use-cases for object initializers. But before I can give examples, I need to know what you are thinking re:short-hand syntax for constructors? > I don't understand what you mean here. Your example showed a QueryBuilder > class being refactored to use a Query object instead of multiple > parameters, which is something that can happen right now, no language > changes needed. The only new feature your example showed was a different > way of constructing the Query class. This is because of trying to come up with examples that address many different use-cases. It is hard to come up with examples for all use-cases in one sitting. > I agree, and I never said otherwise. I do think that an important part of > deciding whether to implement a feature is evaluating its limitations, and > what use cases it would and wouldn't help with. > > I'm not saying this feature should never happen because it doesn't work > with interfaces, I'm just saying that is a limitation to consider. Understood. 1 of 2 ...continued -Mike
