Closed Lerc closed 5 years ago
I also find myself having to write {a:a, b:b}
from time to time and it's a bit annoying indeed, so I wouldn't be opposed to having this feature. Implementation-wise, the simpliest possible and least invasive approach would be to transform {a, b}
to {a:a,b:b}
at the parser level only. I'll try hacking it up quickly when I get some free time.
I always thought this was pretty meh, especially with good IDE support... IMO we give up some language clarity for the sake of saved keystrokes.
Would this work too: {p.x, p.y}
= {x: p.x, y: p.y}
?
I'm not in favor of it, and there might be some easy macro for that.
On Thu, Sep 13, 2018 at 2:06 PM, Mark Knol notifications@github.com wrote:
Would this work too: {p.x, p.y} = {x: p.x, y: p.y}?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HaxeFoundation/haxe-evolution/pull/51#issuecomment-420983287, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-bwOKL2JZkt5DfCT6UugttDKmHayGGks5uakpVgaJpZM4WmpKH .
I'm not in favor of it, and there might be some easy macro for that.
I went ahead and wrote a quick'n'dirty one:
class Main {
static function main() {
var a = 1, b = 2;
trace(obj(a, b, c=a+b));
}
macro static function obj(exprs:Array<haxe.macro.Expr>):haxe.macro.Expr {
var fields = [];
for (e in exprs) {
switch e {
case macro $i{name}: fields.push({field: name, expr: e});
case macro $i{name}=$e: fields.push({field: name, expr: e});
case _: haxe.macro.Context.error("unsupported expression", e.pos);
}
}
return {pos: haxe.macro.Context.currentPos(), expr: EObjectDecl(fields)};
}
}
IMO we give up some language clarity for the sake of saved keystrokes.
This is not a matter of keystokes. It is a mater of code clarity. I don't believe it significantly reduces language clarity.
Would this work too: {p.x, p.y} = {x: p.x, y: p.y}
no, however if destructuring assignment were also implemented.
var {x,y}=p;
var q={x,y};
Maxe a piece of code saying 'take x and y from put them in q' The compiler should ideally see no difference to var q={x:p.x,y:p.y}
While I agree that implementing this in a macro is simple enough, unless you have a way of transparently invoking the macro I think you are trading one form of redundant text for another. I doubt I would use a macro for simple cases like {x,y}
, but I would for some larger uses, for example
var accessFunctions = {
sendError,
sendMessage,
sendObject,
remove,
setName,
joinGroup,
leaveGroup};
I suspect the 'there's a macro for that' requires a broarder discussion. While macros are amazing, if every tiny enhancement were added though macros then code would become a morass of macro invocations and dependancies. That is pobably a dicussion to be held elsewhere, but it is worth considering. A policy guiding the philosophy behind 'why a macro' and 'why not a macro' would be helpful.
We discussed this and decided to reject it for the reasons already stated.
Where was this discussed and decided? If it were elsewhere I would have liked to have been able to participate. If the discussion was here only, then the reasoning needs to be elaborated, I would like to address any specific objecttions.
This is not how the process is described as working.
We discussed this in our developer meeting yesterday. I don't know what else to tell you, we simply don't want this syntax.
short version: allow
var myPoint ={x,y};
instead ofvar myPoint ={x:x,y:y};
Rendered version