Ideas on type hinting and named parameters

Mark S. Miller erights at google.com
Tue Jun 9 16:18:54 UTC 2015


On Tue, Jun 9, 2015 at 9:13 AM, Andrea Giammarchi <
andrea.giammarchi at 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 <erights at google.com> wrote:
>
>> On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott <luke at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/25bd904e/attachment.html>


More information about the es-discuss mailing list