Re: Proposal: Optional Static Typing (Part 3)

(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

Re: Proposal: Optional Static Typing (Part 3)

> 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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Proposal: Optional Static Typing (Part 3)

>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

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

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 ?

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

Proposal: Alternative public, private, static syntax and questions

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

Re: Proposal: Optional Static Typing (Part 3)

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