Struct literal syntax for ordered structs {[ key:value, key2:value2 ]}

language proposals
#1

In http://lang.lucee.org/t/syntax-for-ordered-struct-literals/213 and the previous Google Group thread, a front runner syntax emerged for declaring that you wish to use an “ordered” (or “linked”) struct when creating a struct literal. The following two syntaxes would be equivalent:

// syntax 1 (existing)
myStruct = StructNew( "linked" );
myStruct.key1 = "Value 1";
myStruct.key2 = "Value 2";

// syntax 2 (proposed)
myStruct = {[ key1:"Value 1", key2:"Value 2" ]};

What do people think of this specific syntax? Please read here before posting for general guidelines on this type of topic: http://lang.lucee.org/t/about-the-proposals-category/223

1 Like
#2

I think that the proposed construct should not allow for whitespace between the { and [ at the open, nor the ] and } at close, so that the construct is the consecutive sequence of {[ and ]}, just like the operators == and !=

2 Likes
#3

Any good reason to enforce this rule? I think to have a rule, there needs to be a sound reason.

Is this to make parsing the source code easier, and would it be a problem if whitespace was allowed? I’m not discounting that as a rationale, just wondering if that’s the basis for it?

#4

no. it’s for better readability. when you see the curly braces followed immediately by a bracket then you know exactly what it is. if whitespace is allowed then the curly brace might be on one line and the bracket on another – making it much harder to tell what type of data structure that is.

2 Likes
#5

Right. I personally happen to agree with you as far as clarity goes in regards to a coding standard, but those sort of decisions / positions do not belong in the language itself.

But there you go: we have both expressed a position now. Let’s see what other people have to say.

#6

What I like - the mix of struct and array notation is immediately instructive to people reading the syntax for the first time (Array = ordered, struct = struct).
Concerns - Mix of [ and { could lead to confusion, especially when not layed out well
Mitigating ideas - As @21Solutions suggested, forcing zero whitespace between { and [, and ] and } should mitigate the confusion of array and struct syntaxes and force treating the character combinations more like a single character.
Gut - I’m a little on the fence, but siding towards supporting its implementation

#7

Using the square bracket looks confusing in term of readability (Array vs Struct).

Suggested some more alternatives here: http://lang.lucee.org/t/syntax-for-ordered-struct-literals/213/14

2 Likes
#8

I disagree. just like you have other operators that are made of other characters without whitespace, like !=, ==, and ===, you can set {[ and ]} to be the operator.

2 Likes
#9

It’s possibly worth noting that by mandating zero whitespace you remove the overhead of stripping the whitespace when the language interpreter is deciding whether the { is the opening tag of a a “default” struct, or whether it’s the opening tag of {[.

#10

I think Igal made a reasonable point before with his example of other operands. Sorry… saw it at the time and meant to reply but never got around to it.

On this one (Simon’s point) though: it’s a compile time thing, so doesn’t really matter in the bigger scheme of things. Code only compiles once for the lifetime of the app, after all. This sort of thing in and of itself ought not be an economy one concerns one’s self with.

Anyway, this is just minutiae. It’s a good idea: that’s the main thing.