I agree the main proposal is long and complex, but this kind of addition
could be designed with little effort to "fall out of the grid", since it
has so much in common with classes already (properties, getters/setters,
methods). The main question is with properties, but those are easy to just
leave out, since function calls do just as well.
Function declaration/expression/parameter decorators are completely
different beasts with little in common, so I feel it's a bad comparison.
On Thu, Jun 28, 2018, 01:33 Augusto Moura <augusto.borg...@gmail.com> wrote:
> On June 27, 2018 09:23, kai zhu <kaizhu...@gmail.com> wrote:
> > what would happen if you tried to JSON.stringify foo? a core-value of
> javascript to industry is as an idiot-proof/least-surprise language for
> serializing json-data across browser <-> server. junior-programmers who
> naively employ hard-to-serialize things like custom-getters in their
> low-level code, mostly end up annoying senior-programmers when they have to
> debug high-level integration-code that have problems baton-passing those
> states around.
>
> Depends on the chosen implementation (which will be open for discussion
> for sure). The Groovy AST transformation annotation `@Lazy` for example
> translates the field into a getter (without a setter, making it virtually a
> readonly field) which initializes the field once at the first invocation
> (there is a example of the generated code at Groovy docs[1]). If we follow
> this path we can easily implement it in Javascript as a enumerable get
> property descriptor. About `JSON.stringify`, it renders all enumerable
> properties of a object, including getters, so it will initialize the field
> and represent it as any other property. My previous decorator example could
> be loosely interpreted as:
>
> ```js
> const foo = {
> get bar() {
> if (!this.hasOwnProperty('_bar')) {
> this._bar = 3;
> }
> return this._bar;
> },
> };
>
> // JSON.stringify would write the correct bar value, initalizing it if
> necessary
> JSON.stringify(foo) // "{"bar":3}"
> ```
>
> We could make a setter too, but the logic to implement it it's a lot more
> complex and subject to confusion
>
> On June 27, 2018 10:11, Isiah Meadows <isiahmead...@gmail.com> wrote:
> > If you're wanting to propose new places for decorators, you'd have much
> better luck here: https://github.com/tc39/proposal-decorators
>
> I think that the main proposal is already long and complex, maybe it's a
> better idea to finalize it first and then start a new proposal about this
> others decorators places (as with function expression decorators and
> function parameters decoratos).
>
> [1] http://groovy-lang.org/metaprogramming.html#xform-Lazy
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
