On Mon, May 02, 2016 at 12:05:13PM +1000, Chris Angelico wrote:
This would be restricted to lookups on simple names. Frankly, I wouldn't expect anything else.
And I completely disagree. If this proposal is for simple names alone, I don't want it -- it would be one more syntactic feature to learn for virtually no benefit to the reader or the writer. (If the name is so long as to be a burden to type, copy and paste it.)
If you want to call "myobject[1].lookup['key'].property.a" and "etc etc .b", you should probably be giving that a name *for the benefit of humans*
That goes completely against the advice "use a temporary one-letter name". Using, let's say, "x" or "m" for the variable name is not really for the benefit of the reader, otherwise it would be given a meaningful name like current_record_address. But that obviously goes against the idea of reducing the amount needed to type/read. *Whatever* solution you use, whether it is the one-letter temp name, or some variation on Pascal-with/using, you are compromising explicitness for convenience and/or efficiency. If this is worth doing, it has to be worth doing for complex references not just simple names. Otherwise, what's the point? Just use a shorter name.
never mind about the interpreter! And if you want it optimized, definitely assign that to a local name.
If you have to create a one-off function just to get access to a local variable, the cost of creating a function will surely blow away any realistic gains you might get from using a local name. That shouldn't apply to the "using" block, which can use the same reference without needing to create a function object. If I'm reading you correctly, you're suggesting that (1) "using" should be limited to simple names, and (2) any (hypothetical) optimization should be only applied if the name is a function local, not inside a class definition or global scope. With these restrictions, the value of this feature keeps going down and down and down, to the point that it is not worth adding it. There is cost to new syntactic features, and once you strip away most of the benefits, you're left with something that is no longer worth the effort of adding and learning the new syntax. So a very strong -1 on the crippled/restricted version of "using", and a tentative +1 for the unrestricted version if it can be shown that there are significant performance gains to be made over the temp name version. (I'm still not quite 100% convinced that the benefit outways the "grit on Tim's monitor rule", but I'm leaning that way.) -- Steve