(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
> 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 hardw
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 shorth
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
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 cla
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
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
>
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 prob
>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
ru
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
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 ev
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
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 in
13 matches
Mail list logo