augusto.borgesm at gmail.com (2018-06-28T05:44:18.392Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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-Lazyaugusto.borgesm at gmail.com (2018-06-28T05:43:58.467Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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-Lazyaugusto.borgesm at gmail.com (2018-06-28T05:43:27.451Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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-Lazyaugusto.borgesm at gmail.com (2018-06-28T05:42:37.553Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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#xformaugusto.borgesm at gmail.com (2018-06-28T05:41:30.984Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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#xformaugusto.borgesm at gmail.com (2018-06-28T05:41:18.330Z)
> On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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#xformaugusto.borgesm at gmail.com (2018-06-28T05:40:30.108Z)
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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
On June 27, 2018 09:23, kai zhu <kaizhu256 at 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 <isiahmeadows at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180628/9ff19705/attachment.html>