Ideas on type hinting and named parameters

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Jun 9 16:56:33 UTC 2015


TypeScript was just an example, but being class a different Syntax beast
than just prototype (right?) why would that be bad? It will be indeed
not-unexpected as Kevin mentioned later on.

Using classes thinking prototypes feel something developers won't do
(specially new comers) so TypeScript behavior looks OKish to me, but in ES7
doesn't have to be like that, it can be actually part of the prototype if
you prefer, and do a copy of non primitives ( or leave the Kevin's
mentioned footgun in, I don't mind, it never hurt me personally :-) )

Regards

On Tue, Jun 9, 2015 at 5:18 PM, Mark S. Miller <erights at google.com> wrote:

>
>
> 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/0cace1d5/attachment-0001.html>


More information about the es-discuss mailing list