Implied Field Names on Object Literals

[Lerc]

short version: allow var myPoint ={x,y}; instead of var myPoint ={x:x,y:y};

Rendered version

[kLabz]

Rendered version

[nadako]

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.

[Simn]

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.

[markknol]

Would this work too: {p.x, p.y} = {x: p.x, y: p.y}?

[ncannasse]

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 .

[nadako]

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)};
    }
}

[Lerc]

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.

[Simn]

We discussed this and decided to reject it for the reasons already stated.

[Lerc]

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.

[Simn]

We discussed this in our developer meeting yesterday. I don't know what else to tell you, we simply don't want this syntax.