Re: Proposal: Optional Static Typing (Part 3)

[Jordan Harband]

(btw the SIMD proposal has been dropped to stage 1, and implementations are
not pursuing implementing it in JS for now
https://github.com/tc39/proposals/blob/master/inactive-proposals.md)

On Thu, Jan 11, 2018 at 9:18 PM, Brandon Andrews <
warcraftthre...@sbcglobal.net> wrote:

> > I'm still yet to read the entire proposal, but with a quick skim, it
> seems to me like this is essentially what Typescript or Flow offers you:
> i.e. an opt-in type system?
>
> This is in the core of ECMAScript, so the types would be real. The
> implementers would be encouraged to use native hardware types. But yes,
> outside of that it is an opt-in type system. Language built on top of it
> would then benefit from this. I often wonder if languages built on top of
> ES6 haven't limited themselves because types don't exist. That is they'd do
> more, but didn't because the complexity of transpiling. Stuff like this:
> https://github.com/Microsoft/TypeScript/issues/4639 Imagine if ECMAScript
> already had all those types and support function overloading. TypeScript
> could move on and implement more experimental ideas.
>
> > I'm wondering if you have any good reasons to want there to be a
> standardised static type annotation syntax within ECMAScript instead of a
> "Bring Your Own Type Checker" system. If you do have some thoughts on this,
> you might also want to include that as a preface on your Github's
> README.You have a "Rationale" bit that seems to ignore the existence of
> these existing systems.
>
> Did you read the rationale? It specifically says:
>
> > The demand for types as a different approach to code has been so strong
> in the past few years that separate languages have been created to deal
> with the perceived shortcomings.
>
> More of the rationale was below the types proposed. I've moved it up into
> the rationale since it fits better there. If there's more you think should
> be added I'll include it. I'm trying to keep things concise since it's a
> long proposal. I could go into an explanation that TypeScript and other
> languages are generally just a superset of Javascript and benefit from
> bringing their features closer to the base language and possibly the
> hardware? It seems too obvious to me to write something like that.
>
>
>
>
> > From a quick read, I'm more in favor of something that's a little more
> restricted to start, something like what Python has. Python has optional
> static type annotations, but the Python interpreter just ignores them. They
> are present purely for the purposes of tooling, and are silently ignored at
> runtime.
>
> The goal with this proposal is to get essentially native hardware types
> where applicable. All the proposed types have special operator rules, value
> ranges (overflow behavior), and in the case of SIMD very real performance
> impact behind them. While documentation hints are a side-effect, I'm more
> focused instead for pushing ECMAScript toward being a more powerful
> language. Python is a classic example of where data type shortcomings lead
> to unintuitiveness or weird design like: https://docs.python.org/2/
> library/array.html I'm trying to avoid such things.
>
> > One of the reasons why I'd prefer a simpler approach to start is that
> TypeScript and Flow, the two main implementations that add syntax, have a
> *very* similar syntax, but have several nuances that would make a heavier
> proposal much harder to accomplish:
>
> > - Flow has `?Foo` for optional types, TypeScript just uses unions.
>
> I have a section on unions with a small explanation on why I left it out.
> I kept it simple by only adding nullable types. Right now someone would
> overload or use 'any'.
>
> > - TypeScript has mapped/index types, where Flow uses special named types.
>
> I didn't include these.
>
> > - Flow allows omitted parameter names in function types, TypeScript only
> allows named parameters with implicit `any` types.
>
> I created an issue to be more explicit about optional and default typed
> parameters and the behavior.
>
> > - Flow has exact types, TypeScript doesn't.
>
> I hadn't even considered something like this. It sounds interesting for
> configuration options. They introduce new tokens. Something I'm very much
> avoiding for this initial proposal.
>
> > - Flow has `opaque type`, TypeScript only has `type`.
>
> Something to be decided later. Doesn't create breaking changes to add
> later.
>
> > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
>
> There's a section on generics and why it isn't included already. I'm with
> you that it's far too complex to add in with initial types. There's no
> breaking changes introduced by adding it later. (Mostly because it
> introduces new tokens which would be a huge deal).
>
> > - Flow has existential types, TypeScript doesn't.
>
> I definitely haven't included this. Flow is a few steps ahead of this
> proposal.
>
> It seems like a lot of these features already aren't included in the
> proposal. I 

Re: Proposal: Optional Static Typing (Part 3)

[Brandon Andrews]

> I'm still yet to read the entire proposal, but with a quick skim, it seems to 
> me like this is essentially what Typescript or Flow offers you: i.e. an 
> opt-in type system?

This is in the core of ECMAScript, so the types would be real. The implementers 
would be encouraged to use native hardware types. But yes, outside of that it 
is an opt-in type system. Language built on top of it would then benefit from 
this. I often wonder if languages built on top of ES6 haven't limited 
themselves because types don't exist. That is they'd do more, but didn't 
because the complexity of transpiling. Stuff like this: 
https://github.com/Microsoft/TypeScript/issues/4639 Imagine if ECMAScript 
already had all those types and support function overloading. TypeScript could 
move on and implement more experimental ideas.

> I'm wondering if you have any good reasons to want there to be a standardised 
> static type annotation syntax within ECMAScript instead of a "Bring Your Own 
> Type Checker" system. If you do have some thoughts on this, you might also 
> want to include that as a preface on your Github's README.You have a 
> "Rationale" bit that seems to ignore the existence of these existing systems.

Did you read the rationale? It specifically says:

> The demand for types as a different approach to code has been so strong in 
> the past few years that separate languages have been created to deal with the 
> perceived shortcomings.

More of the rationale was below the types proposed. I've moved it up into the 
rationale since it fits better there. If there's more you think should be added 
I'll include it. I'm trying to keep things concise since it's a long proposal. 
I could go into an explanation that TypeScript and other languages are 
generally just a superset of Javascript and benefit from bringing their 
features closer to the base language and possibly the hardware? It seems too 
obvious to me to write something like that.




> From a quick read, I'm more in favor of something that's a little more 
> restricted to start, something like what Python has. Python has optional 
> static type annotations, but the Python interpreter just ignores them. They 
> are present purely for the purposes of tooling, and are silently ignored at 
> runtime.

The goal with this proposal is to get essentially native hardware types where 
applicable. All the proposed types have special operator rules, value ranges 
(overflow behavior), and in the case of SIMD very real performance impact 
behind them. While documentation hints are a side-effect, I'm more focused 
instead for pushing ECMAScript toward being a more powerful language. Python is 
a classic example of where data type shortcomings lead to unintuitiveness or 
weird design like: https://docs.python.org/2/library/array.html I'm trying to 
avoid such things.

> One of the reasons why I'd prefer a simpler approach to start is that 
> TypeScript and Flow, the two main implementations that add syntax, have a 
> *very* similar syntax, but have several nuances that would make a heavier 
> proposal much harder to accomplish:

> - Flow has `?Foo` for optional types, TypeScript just uses unions.

I have a section on unions with a small explanation on why I left it out. I 
kept it simple by only adding nullable types. Right now someone would overload 
or use 'any'.

> - TypeScript has mapped/index types, where Flow uses special named types.

I didn't include these.

> - Flow allows omitted parameter names in function types, TypeScript only 
> allows named parameters with implicit `any` types.

I created an issue to be more explicit about optional and default typed 
parameters and the behavior.

> - Flow has exact types, TypeScript doesn't.

I hadn't even considered something like this. It sounds interesting for 
configuration options. They introduce new tokens. Something I'm very much 
avoiding for this initial proposal.

> - Flow has `opaque type`, TypeScript only has `type`.

Something to be decided later. Doesn't create breaking changes to add later.

> - Flow constrains with `T: Super`, TypeScript uses `T extends Super`.

There's a section on generics and why it isn't included already. I'm with you 
that it's far too complex to add in with initial types. There's no breaking 
changes introduced by adding it later. (Mostly because it introduces new tokens 
which would be a huge deal).

> - Flow has existential types, TypeScript doesn't.

I definitely haven't included this. Flow is a few steps ahead of this proposal.

It seems like a lot of these features already aren't included in the proposal. 
I definitely hold your view that the proposal has to be minimal, but I think my 
minimal is functionally minimal. Something that when implemented allows 
developers to experiment and then discussion can progress from there to how 
more features can be added. I'm trying to be thourough though as to not harm a 
future proposal so if any of my decisions block something I'm open to 

Re: Proposal: Alternative public, private, static syntax and questions

[Logan Smyth]

The `#foo` shorthand part of the proposal was removed: https://github.com/
tc39/proposal-class-fields/issues/21

On Thu, Jan 11, 2018 at 2:26 PM, Isiah Meadows 
wrote:

> The proposal does a very poor job of explaining this, but `#foo` is a
> shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
> foo}`. That kind of thing has precedent in other languages:
> CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's
> not private), and Ruby uses `@foo` as a shorthand for `self.foo`
> (which is private by default). Most traditional strongly typed OO
> languages just let you omit `this` and just reference the property as
> if it were a variable in scope, without the sigil, and Ruby does as
> well for methods.
>
> It saves 5 characters in the most common case, accessing private
> properties of the current instance.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Thu, Jan 11, 2018 at 4:26 PM, Naveen Chawla 
> wrote:
> > I hadn't read the proposal properly, but the thrust of my point is the
> same,
> > read remove/add `#` instead of "replace with this"
> >
> >
> > On Fri, 12 Jan 2018, 2:47 am Naveen Chawla, 
> wrote:
> >>
> >> Massive drawback of the # semantic: making a private variable public (a
> >> common transition when the usage of a class evolves) requires a lot more
> >> refactoring, since you have to remove every # for the variable across
> the
> >> class and replace it with `this`. Failing to do so in just 1 instance
> >> creates a bug. The same drawback applies for privatizing a public
> variable,
> >> in reverse.
> >>
> >> Besides which as an instance variable I want to learn `this` as the
> access
> >> prefix. I don't want to have to learn 2 different access prefixes, one
> for
> >> public and one for private. Access control in code only has one real
> >> material advantage: simplifying the public interface of a class by
> hiding
> >> factors that have no use from outside it. This is not big enough of an
> >> advantage to introduce a new access prefix, which can lead to a
> plethora of
> >> bugs due to confusion and/or publicization/privatization transitions
> during
> >> the evolution of one's system.
> >>
> >>
> >> On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, 
> >> wrote:
> >>>
> >>> Inline
> >>>
> >>> -
> >>>
> >>> Isiah Meadows
> >>> m...@isiahmeadows.com
> >>>
> >>> Looking for web consulting? Or a new website?
> >>> Send me an email and we can get started.
> >>> www.isiahmeadows.com
> >>>
> >>> On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
> >>>  wrote:
> >>> >
> >>> > That is a very useful document. I guess I haven't opened the proposal
> >>> > in a while.
> >>> >
> >>> >
> >>> > He puts a lot of stress on preserving encapsulation where as I was
> >>> > planning on relying on a type system to optionally provide that
> feature.
> >>> > That is given a dynamically typed variable accessing privates would
> probably
> >>> > be allowed. (Statically typed variables would detect and not allow
> that kind
> >>> > of like a more strict usage).
> >>>
> >>> The issue with leveraging static typing is that JS has never been a
> >>> statically typed language. Also, private fields are generally
> >>> something you shouldn't need static types to detect - even without the
> >>> sigil, it *is* in fact possible to require something like `private
> >>> foo` as a declaration and alter property lookup within classes to
> >>> check for local private names (for class instances) before public
> >>> ones. (Decided to create a GH issue out of this:
> >>> https://github.com/tc39/proposal-class-fields/issues/69)
> >>>
> >>> > I think the inheritance and using private names as keys are decent
> >>> > arguments. That said I'm personally not against allowing inherited
> classes
> >>> > access to their base class private members though. That is private
> acting
> >>> > like protected in C++ I think is fine for ECMAScript. Am I alone in
> being
> >>> > fine with that behavior? I'm kind of leaning toward:
> >>> > https://github.com/tc39/proposal-private-fields/issues/14#
> issuecomment-216348883
> >>> > that syntax for a true private class scope variable.
> >>>
> >>> Note: not even Java allows subclasses to access superclasses' private
> >>> fields.
> >>>
> >>> >
> >>> > The key name conflict seems niche outside of key based data
> structures.
> >>> > I wrote an ORM system before and just used a key called "internal"
> to hold
> >>> > data in the past to get around a similar conflict. The # sounds like
> a
> >>> > similar workaround when required but allows everything to not be
> hidden in a
> >>> > nested object which is nice.
> >>> >
> >>> > Are "protected" class fields a thing in this discussion at all? Or is
> >>> > the idea to use or 

Re: Proposal: Alternative public, private, static syntax and questions

[Isiah Meadows]

The proposal does a very poor job of explaining this, but `#foo` is a
shorthand for `this.#foo`, much like `{foo}` is a shorthand for `{foo:
foo}`. That kind of thing has precedent in other languages:
CoffeeScript uses `@foo` as a shorthand for `this.foo` (although it's
not private), and Ruby uses `@foo` as a shorthand for `self.foo`
(which is private by default). Most traditional strongly typed OO
languages just let you omit `this` and just reference the property as
if it were a variable in scope, without the sigil, and Ruby does as
well for methods.

It saves 5 characters in the most common case, accessing private
properties of the current instance.
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Jan 11, 2018 at 4:26 PM, Naveen Chawla  wrote:
> I hadn't read the proposal properly, but the thrust of my point is the same,
> read remove/add `#` instead of "replace with this"
>
>
> On Fri, 12 Jan 2018, 2:47 am Naveen Chawla,  wrote:
>>
>> Massive drawback of the # semantic: making a private variable public (a
>> common transition when the usage of a class evolves) requires a lot more
>> refactoring, since you have to remove every # for the variable across the
>> class and replace it with `this`. Failing to do so in just 1 instance
>> creates a bug. The same drawback applies for privatizing a public variable,
>> in reverse.
>>
>> Besides which as an instance variable I want to learn `this` as the access
>> prefix. I don't want to have to learn 2 different access prefixes, one for
>> public and one for private. Access control in code only has one real
>> material advantage: simplifying the public interface of a class by hiding
>> factors that have no use from outside it. This is not big enough of an
>> advantage to introduce a new access prefix, which can lead to a plethora of
>> bugs due to confusion and/or publicization/privatization transitions during
>> the evolution of one's system.
>>
>>
>> On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, 
>> wrote:
>>>
>>> Inline
>>>
>>> -
>>>
>>> Isiah Meadows
>>> m...@isiahmeadows.com
>>>
>>> Looking for web consulting? Or a new website?
>>> Send me an email and we can get started.
>>> www.isiahmeadows.com
>>>
>>> On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
>>>  wrote:
>>> >
>>> > That is a very useful document. I guess I haven't opened the proposal
>>> > in a while.
>>> >
>>> >
>>> > He puts a lot of stress on preserving encapsulation where as I was
>>> > planning on relying on a type system to optionally provide that feature.
>>> > That is given a dynamically typed variable accessing privates would 
>>> > probably
>>> > be allowed. (Statically typed variables would detect and not allow that 
>>> > kind
>>> > of like a more strict usage).
>>>
>>> The issue with leveraging static typing is that JS has never been a
>>> statically typed language. Also, private fields are generally
>>> something you shouldn't need static types to detect - even without the
>>> sigil, it *is* in fact possible to require something like `private
>>> foo` as a declaration and alter property lookup within classes to
>>> check for local private names (for class instances) before public
>>> ones. (Decided to create a GH issue out of this:
>>> https://github.com/tc39/proposal-class-fields/issues/69)
>>>
>>> > I think the inheritance and using private names as keys are decent
>>> > arguments. That said I'm personally not against allowing inherited classes
>>> > access to their base class private members though. That is private acting
>>> > like protected in C++ I think is fine for ECMAScript. Am I alone in being
>>> > fine with that behavior? I'm kind of leaning toward:
>>> > https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
>>> > that syntax for a true private class scope variable.
>>>
>>> Note: not even Java allows subclasses to access superclasses' private
>>> fields.
>>>
>>> >
>>> > The key name conflict seems niche outside of key based data structures.
>>> > I wrote an ORM system before and just used a key called "internal" to hold
>>> > data in the past to get around a similar conflict. The # sounds like a
>>> > similar workaround when required but allows everything to not be hidden 
>>> > in a
>>> > nested object which is nice.
>>> >
>>> > Are "protected" class fields a thing in this discussion at all? Or is
>>> > the idea to use or implement a friend system later somehow?
>>>
>>> See https://github.com/tc39/proposal-decorators/issues/25.
>>>
>>> >
>>> >
>>> > With how I use Javascript currently, and the direction I want
>>> > ECMAScript to head - toward types - I don't particularly like the proposal
>>> > or necessarily support its goals toward creating an ideal encapsulation.
>>> > (Also I really dislike the syntax).
>>> > 

Re: Proposal: Alternative public, private, static syntax and questions

[Naveen Chawla]

I hadn't read the proposal properly, but the thrust of my point is the
same, read remove/add `#` instead of "replace with this"

On Fri, 12 Jan 2018, 2:47 am Naveen Chawla,  wrote:

> Massive drawback of the # semantic: making a private variable public (a
> common transition when the usage of a class evolves) requires a lot more
> refactoring, since you have to remove every # for the variable across the
> class and replace it with `this`. Failing to do so in just 1 instance
> creates a bug. The same drawback applies for privatizing a public variable,
> in reverse.
>
> Besides which as an instance variable I want to learn `this` as the access
> prefix. I don't want to have to learn 2 different access prefixes, one for
> public and one for private. Access control in code only has one real
> material advantage: simplifying the public interface of a class by hiding
> factors that have no use from outside it. This is not big enough of an
> advantage to introduce a new access prefix, which can lead to a plethora of
> bugs due to confusion and/or publicization/privatization transitions during
> the evolution of one's system.
>
> On Fri, 12 Jan 2018, 1:22 am Isiah Meadows, 
> wrote:
>
>> Inline
>>
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>> On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
>>  wrote:
>> >
>> > That is a very useful document. I guess I haven't opened the proposal
>> in a while.
>> >
>> >
>> > He puts a lot of stress on preserving encapsulation where as I was
>> planning on relying on a type system to optionally provide that feature.
>> That is given a dynamically typed variable accessing privates would
>> probably be allowed. (Statically typed variables would detect and not allow
>> that kind of like a more strict usage).
>>
>> The issue with leveraging static typing is that JS has never been a
>> statically typed language. Also, private fields are generally
>> something you shouldn't need static types to detect - even without the
>> sigil, it *is* in fact possible to require something like `private
>> foo` as a declaration and alter property lookup within classes to
>> check for local private names (for class instances) before public
>> ones. (Decided to create a GH issue out of this:
>> https://github.com/tc39/proposal-class-fields/issues/69)
>>
>> > I think the inheritance and using private names as keys are decent
>> arguments. That said I'm personally not against allowing inherited classes
>> access to their base class private members though. That is private acting
>> like protected in C++ I think is fine for ECMAScript. Am I alone in being
>> fine with that behavior? I'm kind of leaning toward:
>> https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
>> that syntax for a true private class scope variable.
>>
>> Note: not even Java allows subclasses to access superclasses' private
>> fields.
>>
>> >
>> > The key name conflict seems niche outside of key based data structures.
>> I wrote an ORM system before and just used a key called "internal" to hold
>> data in the past to get around a similar conflict. The # sounds like a
>> similar workaround when required but allows everything to not be hidden in
>> a nested object which is nice.
>> >
>> > Are "protected" class fields a thing in this discussion at all? Or is
>> the idea to use or implement a friend system later somehow?
>>
>> See https://github.com/tc39/proposal-decorators/issues/25.
>>
>> >
>> >
>> > With how I use Javascript currently, and the direction I want
>> ECMAScript to head - toward types - I don't particularly like the proposal
>> or necessarily support its goals toward creating an ideal encapsulation.
>> (Also I really dislike the syntax).
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

[Naveen Chawla]

Massive drawback of the # semantic: making a private variable public (a
common transition when the usage of a class evolves) requires a lot more
refactoring, since you have to remove every # for the variable across the
class and replace it with `this`. Failing to do so in just 1 instance
creates a bug. The same drawback applies for privatizing a public variable,
in reverse.

Besides which as an instance variable I want to learn `this` as the access
prefix. I don't want to have to learn 2 different access prefixes, one for
public and one for private. Access control in code only has one real
material advantage: simplifying the public interface of a class by hiding
factors that have no use from outside it. This is not big enough of an
advantage to introduce a new access prefix, which can lead to a plethora of
bugs due to confusion and/or publicization/privatization transitions during
the evolution of one's system.

On Fri, 12 Jan 2018, 1:22 am Isiah Meadows,  wrote:

> Inline
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
> On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
>  wrote:
> >
> > That is a very useful document. I guess I haven't opened the proposal in
> a while.
> >
> >
> > He puts a lot of stress on preserving encapsulation where as I was
> planning on relying on a type system to optionally provide that feature.
> That is given a dynamically typed variable accessing privates would
> probably be allowed. (Statically typed variables would detect and not allow
> that kind of like a more strict usage).
>
> The issue with leveraging static typing is that JS has never been a
> statically typed language. Also, private fields are generally
> something you shouldn't need static types to detect - even without the
> sigil, it *is* in fact possible to require something like `private
> foo` as a declaration and alter property lookup within classes to
> check for local private names (for class instances) before public
> ones. (Decided to create a GH issue out of this:
> https://github.com/tc39/proposal-class-fields/issues/69)
>
> > I think the inheritance and using private names as keys are decent
> arguments. That said I'm personally not against allowing inherited classes
> access to their base class private members though. That is private acting
> like protected in C++ I think is fine for ECMAScript. Am I alone in being
> fine with that behavior? I'm kind of leaning toward:
> https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
> that syntax for a true private class scope variable.
>
> Note: not even Java allows subclasses to access superclasses' private
> fields.
>
> >
> > The key name conflict seems niche outside of key based data structures.
> I wrote an ORM system before and just used a key called "internal" to hold
> data in the past to get around a similar conflict. The # sounds like a
> similar workaround when required but allows everything to not be hidden in
> a nested object which is nice.
> >
> > Are "protected" class fields a thing in this discussion at all? Or is
> the idea to use or implement a friend system later somehow?
>
> See https://github.com/tc39/proposal-decorators/issues/25.
>
> >
> >
> > With how I use Javascript currently, and the direction I want ECMAScript
> to head - toward types - I don't particularly like the proposal or
> necessarily support its goals toward creating an ideal encapsulation. (Also
> I really dislike the syntax).
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

[Isiah Meadows]

Inline

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com

On Thu, Jan 11, 2018 at 2:10 PM, Brandon Andrews
 wrote:
>
> That is a very useful document. I guess I haven't opened the proposal in a 
> while.
>
>
> He puts a lot of stress on preserving encapsulation where as I was planning 
> on relying on a type system to optionally provide that feature. That is given 
> a dynamically typed variable accessing privates would probably be allowed. 
> (Statically typed variables would detect and not allow that kind of like a 
> more strict usage).

The issue with leveraging static typing is that JS has never been a
statically typed language. Also, private fields are generally
something you shouldn't need static types to detect - even without the
sigil, it *is* in fact possible to require something like `private
foo` as a declaration and alter property lookup within classes to
check for local private names (for class instances) before public
ones. (Decided to create a GH issue out of this:
https://github.com/tc39/proposal-class-fields/issues/69)

> I think the inheritance and using private names as keys are decent arguments. 
> That said I'm personally not against allowing inherited classes access to 
> their base class private members though. That is private acting like 
> protected in C++ I think is fine for ECMAScript. Am I alone in being fine 
> with that behavior? I'm kind of leaning toward: 
> https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
>  that syntax for a true private class scope variable.

Note: not even Java allows subclasses to access superclasses' private fields.

>
> The key name conflict seems niche outside of key based data structures. I 
> wrote an ORM system before and just used a key called "internal" to hold data 
> in the past to get around a similar conflict. The # sounds like a similar 
> workaround when required but allows everything to not be hidden in a nested 
> object which is nice.
>
> Are "protected" class fields a thing in this discussion at all? Or is the 
> idea to use or implement a friend system later somehow?

See https://github.com/tc39/proposal-decorators/issues/25.

>
>
> With how I use Javascript currently, and the direction I want ECMAScript to 
> head - toward types - I don't particularly like the proposal or necessarily 
> support its goals toward creating an ideal encapsulation. (Also I really 
> dislike the syntax).
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Alternative public, private, static syntax and questions

[Brandon Andrews]

That is a very useful document. I guess I haven't opened the proposal in a 
while.


He puts a lot of stress on preserving encapsulation where as I was planning on 
relying on a type system to optionally provide that feature. That is given a 
dynamically typed variable accessing privates would probably be allowed. 
(Statically typed variables would detect and not allow that kind of like a more 
strict usage).
I think the inheritance and using private names as keys are decent arguments. 
That said I'm personally not against allowing inherited classes access to their 
base class private members though. That is private acting like protected in C++ 
I think is fine for ECMAScript. Am I alone in being fine with that behavior? 
I'm kind of leaning toward: 
https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883
 that syntax for a true private class scope variable.

The key name conflict seems niche outside of key based data structures. I wrote 
an ORM system before and just used a key called "internal" to hold data in the 
past to get around a similar conflict. The # sounds like a similar workaround 
when required but allows everything to not be hidden in a nested object which 
is nice.

Are "protected" class fields a thing in this discussion at all? Or is the idea 
to use or implement a friend system later somehow?

With how I use Javascript currently, and the direction I want ECMAScript to 
head - toward types - I don't particularly like the proposal or necessarily 
support its goals toward creating an ideal encapsulation. (Also I really 
dislike the syntax).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Optional Static Typing (Part 3)

[Isiah Meadows]

>From a quick read, I'm more in favor of something that's a little more
restricted to start, something like what Python has. Python has optional
static type annotations, but the Python interpreter just ignores them. They
are present purely for the purposes of tooling, and are silently ignored at
runtime.

Conversely, PHP took a similar approach and initially also made it cosmetic
to start, only later taking advantage of *some* type annotations by adding
runtime behavior to some of the simpler ones (like primitives).

One of the reasons why I'd prefer a simpler approach to start is that
TypeScript and Flow, the two main implementations that add syntax, have a
*very* similar syntax, but have several nuances that would make a heavier
proposal much harder to accomplish:

- Flow has `?Foo` for optional types, TypeScript just uses unions.
- TypeScript has mapped/index types, where Flow uses special named types.
- Flow allows omitted parameter names in function types, TypeScript only
allows named parameters with implicit `any` types.
- Flow has exact types, TypeScript doesn't.
- Flow has `opaque type`, TypeScript only has `type`.
- Flow constrains with `T: Super`, TypeScript uses `T extends Super`.
- Flow has 3 different ways of importing bindings a module (depending on
what's being imported), TypeScript only has one.
- Flow has existential types, TypeScript doesn't.

Also, both TypeScript and Flow are still working out how to properly type
some of the more advanced JS (like variadic functions and auto-curried
functions), so their syntax is *still* not exactly stable enough I'd feel
comfortable encoding much into the spec. (They do have a stable core,
though.)

One other thing is that multiple active proposals could end up requiring TS
and/or Flow to substantially change parts of their syntax, including:

- Private [fields][1] and [methods][2] (stage 3 and 2 respectively, affects
TS)
- [First class protocols][3] (stage 1, affects both TS and Flow)
- [Typed literals][4] (stage 1, affects TS mostly)

[1]: https://github.com/tc39/proposal-class-fields
[2]: http://github.com/tc39/proposal-static-class-features/
[3]: https://github.com/michaelficarra/proposal-first-class-protocols
[4]: https://github.com/mikewest/tc39-proposal-literals

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com

On Thu, Jan 11, 2018 at 3:09 AM, Pranay Prakash  wrote:

> I'm still yet to read the entire proposal, but with a quick skim, it seems
> to me like this is essentially what Typescript or Flow offers you: i.e. an
> opt-in type system?
>
> I'm wondering if you have any good reasons to want there to be a
> standardised static type annotation syntax within ECMAScript instead of a
> "Bring Your Own Type Checker" system.
> If you do have some thoughts on this, you might also want to include that
> as a preface on your Github's README.You have a "Rationale" bit that seems
> to ignore the existence of these existing systems.
>
> Waiting to hear more thoughts on this :)
>
> On Thu, 11 Jan 2018 at 11:56 Brandon Andrews <
> warcraftthre...@sbcglobal.net> wrote:
>
>> It's been a year and a half since my last post and I've made a number of
>> small changes and corrections over 2.5 years. The proposal is still on my
>> github at:
>>
>>
>> https://github.com/sirisian/ecmascript-types
>>
>> I've talked to a lot of people about it, but I haven't gotten much
>> criticism or suggested improvements. I'm a bit in over my head in trying to
>> flesh out all the details or all the nuanced syntax changes that a
>> championed proposal would be expected to do. That said I've been making
>> more changes lately to try to find edge cases and potential problems.
>>
>>
>> I've been jotting down issues here: https://github.com/sirisian/
>> ecmascript-types/issues I closed a number of them recently as I made
>> changes.
>>
>> If anyone has any comments on what I should expand, look into more, or
>> change I'm open to discussing them here or on github.
>>
>> One issue in particular is this: https://github.com/sirisian/
>> ecmascript-types/issues/15 It covers whether I should introduce a new
>> assignment operator to my proposal. Maybe there's another way to look at it
>> or a different solution. I need fresh eyes on the whole proposal really to
>> get a list of new issues to tackle this year.
>>
>> I'm also not against having one or multiple people champion it and
>> working on it without me. (I haven't been able to dedicate time to read the
>> ECMAScript spec and really understanding the grammar fully so having
>> someone qualified to take over would help the proposal a lot).
>>
>>
>> Thanks for reading the proposal for anyone that has the time.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___

RE: Proposal: Alternative public, private, static syntax and questions

[Augusto Moura]

See
https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md
for
clarification of the `#` sigil choice.


-- 
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: the syntax let decorators ?

[Andy Earnshaw]

I don't like this syntax.  `let` can be used to declare multiple variables,
so how does this work?

```
@inc
let a = 1,
b = 2;
```

Does it only decorate the first, or does it decorate all?  Either way, I
don't think it's flexible enough to be compatible with certain coding
styles.  If it is ever going to work, the decorator should come before the
variable name:

```
let @inc a = 1,
@inc b = 2;
```

On Wed, 27 Dec 2017 at 10:48 郑宇光  wrote:

> do you like syntax like this
>
> ```
> @inc
> let a = 1;
>
> function inc(value) {
>   return value + 1;
> }
> ```
>
> I write a plugin to enable this syntax for test, [javascript let
> decorators](https://github.com/ukari/javascript-let-decorators)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: Alternative public, private, static syntax and questions

[Brandon Andrews]

I created a thread about static constructors a while ago here: 
https://esdiscuss.org/topic/proposal-for-a-static-constructor-and-static-member-variables
 It left me with some design thoughts so I wrote up the following proposal idea 
below, but never posted it because I couldn't understand why the current Stage 
3 private proposal introduced a new token '#'. Maybe I missed something obvious 
in the design of the grammar or the way the internals work, but I didn't 
understand. Also I didn't understand why it does this.#x which seems verbose 
since every language with private members doesn't introduce this clutter. (It's 
like writing private everywhere you use it rather than one place which can't 
really be the simplest implementation right?).


https://github.com/sirisian/ecmascript-public-private-static

In the above proposal above I stuck with 'private' and 'static' keywords since 
it seems closer to other languages. Also I kept with the idea that default 
behavior is public to not introduce breaking changes. Can someone explain why 
ECMAScript can't use something like I proposed?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Optional Static Typing (Part 3)

[Pranay Prakash]

I'm still yet to read the entire proposal, but with a quick skim, it seems
to me like this is essentially what Typescript or Flow offers you: i.e. an
opt-in type system?

I'm wondering if you have any good reasons to want there to be a
standardised static type annotation syntax within ECMAScript instead of a
"Bring Your Own Type Checker" system.
If you do have some thoughts on this, you might also want to include that
as a preface on your Github's README.You have a "Rationale" bit that seems
to ignore the existence of these existing systems.

Waiting to hear more thoughts on this :)

On Thu, 11 Jan 2018 at 11:56 Brandon Andrews 
wrote:

> It's been a year and a half since my last post and I've made a number of
> small changes and corrections over 2.5 years. The proposal is still on my
> github at:
>
>
> https://github.com/sirisian/ecmascript-types
>
> I've talked to a lot of people about it, but I haven't gotten much
> criticism or suggested improvements. I'm a bit in over my head in trying to
> flesh out all the details or all the nuanced syntax changes that a
> championed proposal would be expected to do. That said I've been making
> more changes lately to try to find edge cases and potential problems.
>
>
> I've been jotting down issues here:
> https://github.com/sirisian/ecmascript-types/issues I closed a number of
> them recently as I made changes.
>
> If anyone has any comments on what I should expand, look into more, or
> change I'm open to discussing them here or on github.
>
> One issue in particular is this:
> https://github.com/sirisian/ecmascript-types/issues/15 It covers whether
> I should introduce a new assignment operator to my proposal. Maybe there's
> another way to look at it or a different solution. I need fresh eyes on the
> whole proposal really to get a list of new issues to tackle this year.
>
> I'm also not against having one or multiple people champion it and working
> on it without me. (I haven't been able to dedicate time to read the
> ECMAScript spec and really understanding the grammar fully so having
> someone qualified to take over would help the proposal a lot).
>
>
> Thanks for reading the proposal for anyone that has the time.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss