On Apr 20, 2020, at 16:46, Christopher Barker firstname.lastname@example.org wrote:
On Mon, Apr 20, 2020 at 3:13 PM Andrew Barnert email@example.com wrote:
Sure, it’s a declarative format, it’s just that often it’s intended to be understood as representing an object graph.
I"m not sure the point here -- I was not getting onto detail nor expalingnoi myself well, but I think there are (kind of) three ways to "name" just one piece of data that came from a bunch of JSON:
- a key, as in a dict `data['this']`
- an attribute of an object: `data.this`
- a local variable: `this`
what I was getting at is that there may be a fine line between the dsta version and the object version, but that can go between those easily without typing all the names.
OK, I thought you were saying that line is a serious problem for this proposal, so I was arguing that the same problems actually arise either way, and the same proposal helps both.
Since you weren’t saying that and I misinterpreted you, that whole part of the message is irrelevant. So I’ll strip all the irrelevant bits down to this quote from you that I agree with 100%:
It's only when you have it in a local variable that this whole idea starts to matter.
And I think we also agree that it would be better to make this a dict display feature, and a bunch of other bits.
But here’s the big issue:
If I have 38 locals for all 38 selectors in the API—or, worse, a dynamically-chosen subset of them—then “get rid of those locals” is almost surely the answer, but with just 1? Probably not. And maybe 3 or 4 is reasonable too—
right. but I don't think anyone is suggesting a language change for 1, or even 3-4 names (maybe 4...)
So I think people really are suggesting this for around 4 names.
And I agree that’s kind of a marginal benefit. That’s why I think the whole proposal is marginal. It’s almost never going to be a huge win—but it may be a small win in so many places that it adds up to being worth it.