On Sun, Mar 29, 2020, at 3:57 PM, Jakob Givoni wrote:
> Hi Rowan,
>
> On Sun, Mar 29, 2020 at 10:00 AM Rowan Tommins <rowan.coll...@gmail.com>
> wrote:
>
> >
> > myObj.with {
> > foo = 10
> > bar = foo + 20
> > }
> >
>
> I really like the suggested "with" syntax, - in fact I had
> contemplated something like that along the way.
> The slight "problem", I think, is that, as you mention, adding a fully
> fledged "with" syntax would imply that you could do a lot more than simply
> assigning values to properties.
> And while I agree that that would be cool, it feels like overkill for the
> actual problem COPA is trying to solve.
> Do you think a narrow version of "with" syntax could be incorporated into
> COPA without causing frustration? Or would it be wise to give it its own
> RFC?
>
> I haven't researched if there have already been RFCs proposing something
> along the lines of "with", and as such I have no idea if it has already
> been discussed and found problematic.
>
>
> > I'm not sure whether I like this idea or not, but I thought I'd share
> > it, because I think COPA as currently proposed is too narrow a use case
> > to deserve a special syntax.
> >
>
> I understand and fully agree that COPA is narrow, but I don't really
> understand why that's a problem - I proposed it exactly because I felt that
> its simplicity is its force.
> Low hanging fruit is usually something I would encourage to go after.
> I believe it's a trivial implementation that can help in uncountable
> situations where you just need to assign values to a predefined data
> structure in a single expression.
>
> I'd really like to hear the arguments against such a cost-benefit
> calculation.
>
> Cheers,
> Jakob
I went into this in my earlier Object Ergonomics post, but in short, it's quite
possible for a solution to be *too* narrow. It becomes useful in too small a
subset of cases to justify its added conceptual weight (and contrary to the
view of some, "if you don't like it don't use it" is just not a thing when
you're working in OSS, because someone is going to use it and you'll inherit
that code). A narrow solution can also inadvertently serve to make something
too easy that should be done rarely.
In this case, the problem with COPA as proposed is that it only works for
public properties that are assigned literally. That is, in my experience, a
very rare case. Most objects want and need to have private or protected
properties for a large variety of reasons, which would make COPA useless. Or
it would nudge users toward making more properties public so that they can use
the shorter COPA, but in the absence of a readonly keyword, asymmetric
visibility, property accessor, or something along those lines that is a net
loss as it means more properties become public when they really shouldn't be.
In that case, a broader, less narrow solution is superior: Look at the actual
pain points generally, find out their common elements, and address those. IMO,
the combination of constructor promotion and named parameters would have a much
better ROI than a dedicated syntax, it would not suffer from the public
properties problem, it would still allow for constructor parameters that are
not a 1:1 map to properties, but it would still serve to greatly reduce the
amount of typing needed. That is, that approach offers more functionality for
roughly the same or less additional syntax.
In short, the cost-benefit calculation says this is useful in too narrow a
case, and has the potential to encourage bad design in the name of typing less.
Other alternatives address that problem space better.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
