a year ago I was big fan of [expr] since it was so dynamic, but it
clashes (visually) with planned Object Model Reformation. OMR is
probably the higher priority for the future, so I'd suggest let's find
something else instead of [expr] to make run-time symbols usable.
What I see:
A. Just max-min it.
This does not remove the [expr], but does not put fully-fledged one into
the language. The proposal is simple: only allow [expr] if expr is
Identifier. It will allow to use runtime symbols, but will clash
visually with OMR later.
B. foo.[expr], [expr]:..., [expr] () {...}
This proposes to allow [expr] after dot (where Identifier now is, and
where @name was just a few days ago as well). Also make .[expr] the new
low-level construct to access properties programmatically. IOW, instead
of explaining that foo.bar is sugar for foo["bar"], now you will explain
that foo.bar is sugar for foo.["bar"], and foo["bar"] is by_default
equivalent to foo.["bar"] but is (planned to be) configurable.
C. (constrained) foo. at pexpr, @pexpr:..., @pexpr () {...}
This is just a variation of B, but with two distinctions:
syntax not clashing visually with OMR
restrained (not-so-max-minned) at the beginning.
This would propose that one can use @PrimaryExpression after the dot and
as the name of property/concise method in literals and classes, but this
PrimaryExpression would be restrained for initial release to Identifier
or StringLiteral. As B, this should become the new low-level property
access. It is envisionable that later it can be use with other
expressions including foo.@("bar"+"baz"). But for now, only Identifier
(which allow use of symbols) and StringLiteral (to be able to explain
that foo.bar is sugar to foo.@"bar".
Hello,
a year ago I was big fan of [expr] since it was so dynamic, but it
clashes (visually) with planned Object Model Reformation. OMR is
probably the higher priority for the future, so I'd suggest let's find
something else instead of [expr] to make run-time symbols usable.
What I see:
A. Just max-min it.
This does not remove the [expr], but does not put fully-fledged one into
the language. The proposal is simple: only allow [expr] if expr is
Identifier. It will allow to use runtime symbols, but will clash
visually with OMR later.
B. foo.[expr], [expr]:..., [expr] () {...}
This proposes to allow [expr] after dot (where Identifier now is, and
where @name was just a few days ago as well). Also make .[expr] the new
low-level construct to access properties programmatically. IOW, instead
of explaining that foo.bar is sugar for foo["bar"], now you will explain
that foo.bar is sugar for foo.["bar"], and foo["bar"] is _by_default_
equivalent to foo.["bar"] but is (planned to be) configurable.
C. (constrained) foo. at pexpr, @pexpr:..., @pexpr () {...}
This is just a variation of B, but with two distinctions:
- syntax not clashing visually with OMR
- restrained (not-so-max-minned) at the beginning.
This would propose that one can use @PrimaryExpression after the dot and
as the name of property/concise method in literals and classes, but this
PrimaryExpression would be restrained for initial release to Identifier
or StringLiteral. As B, this should become the new low-level property
access. It is envisionable that later it can be use with other
expressions including foo.@("bar"+"baz"). But for now, only Identifier
(which allow use of symbols) and StringLiteral (to be able to explain
that foo.bar is sugar to foo.@"bar".
Herby
Hello,
a year ago I was big fan of [expr] since it was so dynamic, but it clashes (visually) with planned Object Model Reformation. OMR is probably the higher priority for the future, so I'd suggest let's find something else instead of [expr] to make run-time symbols usable.
What I see:
A. Just max-min it.
This does not remove the [expr], but does not put fully-fledged one into the language. The proposal is simple: only allow [expr] if expr is Identifier. It will allow to use runtime symbols, but will clash visually with OMR later.
B. foo.[expr], [expr]:..., [expr] () {...}
This proposes to allow [expr] after dot (where Identifier now is, and where @name was just a few days ago as well). Also make .[expr] the new low-level construct to access properties programmatically. IOW, instead of explaining that foo.bar is sugar for foo["bar"], now you will explain that foo.bar is sugar for foo.["bar"], and foo["bar"] is by_default equivalent to foo.["bar"] but is (planned to be) configurable.
C. (constrained) foo. at pexpr, @pexpr:..., @pexpr () {...}
This is just a variation of B, but with two distinctions:
Hello, a year ago I was big fan of [expr] since it was so dynamic, but it clashes (visually) with planned Object Model Reformation. OMR is probably the higher priority for the future, so I'd suggest let's find something else instead of [expr] to make run-time symbols usable. What I see: A. Just max-min it. This does not remove the [expr], but does not put fully-fledged one into the language. The proposal is simple: only allow [expr] if expr is Identifier. It will allow to use runtime symbols, but will clash visually with OMR later. B. foo.[expr], [expr]:..., [expr] () {...} This proposes to allow [expr] after dot (where Identifier now is, and where @name was just a few days ago as well). Also make .[expr] the new low-level construct to access properties programmatically. IOW, instead of explaining that foo.bar is sugar for foo["bar"], now you will explain that foo.bar is sugar for foo.["bar"], and foo["bar"] is _by_default_ equivalent to foo.["bar"] but is (planned to be) configurable. C. (constrained) foo. at pexpr, @pexpr:..., @pexpr () {...} This is just a variation of B, but with two distinctions: - syntax not clashing visually with OMR - restrained (not-so-max-minned) at the beginning. This would propose that one can use @PrimaryExpression after the dot and as the name of property/concise method in literals and classes, but this PrimaryExpression would be restrained for initial release to Identifier or StringLiteral. As B, this should become the new low-level property access. It is envisionable that later it can be use with other expressions including foo.@("bar"+"baz"). But for now, only Identifier (which allow use of symbols) and StringLiteral (to be able to explain that foo.bar is sugar to foo.@"bar". Herby