On Tue, Jun 9, 2015 at 9:13 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> Mark, properties on the prototype are in TypeScript, and probably every
> other OOP based language. Defaults can be easily defined as such, i.e.
>
> ```js
> class Person { name = 'anonymous'; age = 0; }
> ```
>
At <http://www.typescriptlang.org/Playground>, putting this code into the
left pane causes the right pane to show
var Person = (function () {
function Person() {
this.name = 'anonymous';
this.age = 0;
}
return Person;
})();
which clearly indicates that these are *not* properties on the prototype.
They are per-instance, but merely written with a confusing syntax that
misled you into believing that they were properties on the prototype.
> Not only, defaults could be optimized upfront by parsers without needing
> to infer or do extra analysis on the constructor.
>
> Defaults also as static property/state is quite common.
>
> ```js
> class Admin { PRIVILEGES = 'all'; }
> ```
>
> Anyway, I'm curious to know why do you think getters and setters are OK
> and properties are not. I don't see any technical difference, specially
> considering get/set for lazy property computation/assignment through the
> prototype getter anyway.
>
> JS4lf ... you hit an already opened door about strict descriptors, already
> proposed years ago ;-)
>
>
> https://github.com/WebReflection/define-strict-properties#define-strict-properties
>
> Best Regards
>
>
>
>
>
>
> On Tue, Jun 9, 2015 at 4:44 PM, Mark S. Miller <erig...@google.com> wrote:
>
>> On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott <l...@webconnex.com> wrote:
>> [...]
>>
>>> It currently uses `=` to define properties. And there is some debate
>>> whether or not properties should be initialized in the constructor or be on
>>> the prototype.
>>>
>>
>>
>> There is no debate about whether per-instance state (of whatever form)
>> can be initialized in the constructor. Often, this needs to be initialized
>> to some value dependent on the values of the constructor parameters. Given
>> that we have no choice about supporting initialization in constructors, the
>> debate is *only* about whether we should also bother to support
>> initialization in the class body outside the constructor. IMO, no. Why add
>> a redundant and less expressive mechanism?
>>
>> As for properties on the prototype, these are rarely enough motivated
>> that doing it imperatively after class initialization seems fine. I don't
>> recall anyone strongly advocating that we need syntactic support for
>> properties on the prototype, though perhaps I missed it.
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
