Define static properties and prototype properties with the class syntax

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Dec 14 07:40:53 PST 2014


as side note, I wonder why static hasn't been considered definable as
group/object

```js
class Foo {
  static {
    bar: 'bar',
    get defaults() {
      return {de:'faults'};
    }
  }
}
```

it would be something like "nothing new to learn" and primitives, as both
getters and setters, will be possible, together with public static methods.

It will also make the definition somehow cleaner (one place instead of
potentially many down the class definition) and it will probably avoid
confusion with the `this` reference which will be the class itself and not
an instance.

Would any of this make sense for ES7 ?

Best Regards




On Sat, Dec 13, 2014 at 7:44 PM, Rick Waldron <waldron.rick at gmail.com>
wrote:
>
> Glen,
>
> The closest I can offer is the attendance record of committee meetings. I
> keep a record at the beginning of each day of notes here:
> https://github.com/rwaldron/tc39-notes/tree/master/es6 . It's not 100%
> complete, of course, as not all members can attend every meeting, but it's
> close.
>
> Rick
>
> On Sat Dec 13 2014 at 2:10:00 PM Glen Huang <curvedmark at gmail.com> wrote:
>
>> Hey Rick,
>>
>> Thank you for the explanation and sample code. I made a mistake there. I
>> was demonstrating that the syntax already allows an object to exist in the
>> prototype chain, so the static keyword really shouldn’t be there.
>>
>> And you know, I’m still struggling with the idea of an object being in
>> the prototype chain is a bad one or not. I think for people who know what
>> they are doing, it definitely helps. But if the language wants to prevent
>> footgun features for everybody, it seems that it does make sense to make it
>> more limited. So I’m torn right know.
>>
>> I know you are in the TC39 team (Frankie and Kevin might also be on the
>> team, I’m not sure, would be interested to know if there is a TC39 team
>> member list), and I’d be grateful if you could share your thoughts on this.
>>
>> Thank you.
>>
>> On Dec 14, 2014, at 2:44 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
>>
>>
>>
>> On Sat Dec 13 2014 at 4:54:55 AM Glen Huang <curvedmark at gmail.com> wrote:
>>
>>> But allowing getter & setter already makes it dangerous:
>>>
>>> let _bar = {}
>>> class Foo {
>>>         static get bar() { return _bar; }
>>> }
>>>
>>> Objects that have Foo.prototype in the prototype chain can do
>>> "this.bar.a = 1", and the change won’t be shadowed.
>>>
>>
>> The accessor property "bar" is _not_ created on Foo.prototype, it's
>> created on Foo itself and would not be found on `this`.
>>
>> In ES5, the example above would look like this:
>>
>> var _bar = {};
>> var Foo = function Foo() {}
>>
>> Object.defineProperty(Foo, "bar", {
>>   get: function() {
>>     return _bar;
>>   }
>> });
>>
>>
>>
>>>
>>> I found myself looking for a way to define static properties because I
>>> want to do this:
>>>
>>> function Menu(options) {
>>>         this.options = Object.assign({}, Menu.defaults, options);
>>> }
>>> Menu.defaults = { hidden: false };
>>>
>>>
>>   class Menu {
>>     constructor(options) {
>>        this.options = Object.assign({}, Menu.defaults, options);
>>     }
>>     static get defaults() {
>>       return Object.freeze({ hidden: false });
>>     }
>>   }
>>
>> This has the benefit of preventing unwanted tampering with `Menu.
>> defaults` by ensuring that the only way to modify defaults is by explicitly
>> providing them via  `new Menu({ my opts })`. The property can be _read_ as
>> `Menu.defaults` but assignment to `Menu.defaults` or attempts to change
>> values or add properties will throw.
>>
>>
>>
>>
>>> I want to expose the defaults property so it can be modified by users.
>>> This pattern is very ubiquitous in es5. I wonder if the class syntax could
>>> allow this pattern to be carried to es6?
>>>
>>
>> ES6 is done, but this is something that I also want to revisit for ES7
>> (should be a year following ES6). In the meantime, it's not too painful to
>> address this use case by doing this:
>>
>>   class Menu {
>>     constructor(options) {
>>        this.options = Object.assign({}, Menu.defaults, options);
>>     }
>>   }
>>
>>   Menu.defaults = { hidden: true };
>>
>> Though I'm not sure what the benefit is to allowing any code access to an
>> the unprotected defaults. If you and I are working on a large system using
>> this class, with potentially many Menu components on the same page and I
>> change the defaults, all other code can no longer trust the defaults to be
>> correct. That said, it's not always as simple as creating a closure with
>> the defaults so they're not exposed at all—exposing them is certainly
>> useful for testing, and/or verifying correct, expected initial state with
>> some baseline shape.
>>
>> Rick
>>
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141214/f2bf6a12/attachment.html>


More information about the es-discuss mailing list