On Mon, Sep 16, 2019, at 2:28 PM, Mike Schinkel wrote:
> 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
I think everyone's in agreement about:
1) Making objects easier to work with.
2) Devs should use objects more.
(Side note: I have an article submitted to php[architect] entitled "Never* use
arrays" that goes into this topic in much more detail. I am 100% on board with
getting developers using objects more and arrays less.)
However, why do we want devs to use objects more? If we just want the
arrow-like syntax, then this works today:
$val = (object)[
'foo' => 'bar',
'baz' => 5,
];
And now developers are using an anonymous "object". However, that offers
basically no meaningful improvement except funnier passing semantics.
As I see it, the advantages of using objects over arrays are two fold:
1) The PHP engine is able to make dramatic optimizations when working with
*defined* classes with *defined* properties. I think (although have not
verified) that anonymous classes get the same benefit but iff their properties
are explicitly defined like any other class.
2) They're more self-documenting and statically analyzable (by your IDE or any
other tool)... but that's true only if you have an explicitly defined class!
So I see really no advantage whatsoever in replacing this:
function doSomething(int $a, array $options = []) { ... }
with this:
function doSomething(int $a, object $options = {}) { ... }
It's only an advantage if I do this:
function doSomething(int $a, SomethingOptions $options = null) { ... }
Doing that has many advantages, I think we all agree. But going halfway
doesn't give us any benefits other than swapping [' '] for ->.
What we want to do is make it easier to create $options inline in a
self-documenting way. I'm all for that. But that first requires the developer
still define SomethingOptions somewhere.
So for me, the entire "easier to use anonymous one-off classes" argument falls
apart, because there's no material benefit there other than saying "but now
it's using objects". For that, as noted, we already have an ample syntax that
accomplishes just as much.
So rather than making it easier for people to make "anonymous structs that use
object syntax", we should be making it easier for people to define for-realsies
named classes and using them, because *that* is where the benefit comes from.
And for that part of the problem (making named struct-like classes easier to
work with), as noted in the other thread I find the named
parameters/auto-promotion combination to solve the problem just as well, and
then some.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
