Allen Wirfs-Brock wrote:
Well, strictly speaking the object literal that is the RHS of the
above example is /defining/ properties on a new object and those the
properties of that object are then /assigned/ to corresponding
properties of the LHS object.
Of course, but see below.
Regardless, the associations between the symbols and the semantics
don't have to be perfect they just have to be close enough to have
some mnemonic value.
Here I think you're going to run into trouble. The syntax has to be
pretty sweet to meet general acclamation in the community and to achieve
consensus in TC39.
Language design involves conservative reuse of older languages' design,
some cross-cutting thinking that ideally makes maximum use of a few
cleanly composing primitives, and no mercy for "close enough (but not
quite right)". Symbology is not arbitrary, or no more arbitrary than
history and tradition in the relevant CS subculture.
Yes, JS is in the C family so it has some unusual (to those not
native-born to C or JS) parts. Idioms arise in all practical languages.
But .= is not the clear "assign not define" winner, and := is quite
different from Algol et al. (Pascal, Ada), and Smalltalk (thanks for
reminding me). If the goal is batch assignment, then writing the batch
parts as property definitions in an object literal is mixing "define"
with the outer, later "assign", and .= misplaces the dot. The batch
assignment proposal goes the other way:
obj.{ prop1 = val1; prop2 = val2 ... }
with a more statement-like grammar within braces, yet without recreating
'with'.
I don't know that batch assignment will achieve consensus. The semantics
with nested .{...} occurrences is more powerful than .=, which doesn't
handle nesting (neither does := AFAICT). Whatever the semantics, getting
syntax past the various taste-testers and grammar buffs is a tall order.
I don't think "perfect" is possible but I do think "close enough to have
some mnemonic value" is not sufficient.
If batch assignment including nesting is the winning semantics, the
syntax probably follows and can't use .=. So reserving .= based on :=
(which is not yet in Harmony) seems premature. Sorry to push back, but
after mustache I think we need to be pickier about new syntax.
And (to beat my favorite drum) we must not starve the
polyfillable/no-new-syntax API alternatives (Object.assign,
Object.define or Object.update) in the mean time, where new syntax is
not required by new semantics.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
