Re: Proposal of Multithread JavaScript

Chrome/V8 has it behind a flag IIRC. I forget its exact name, but I know it exists. On Thu, Nov 3, 2016, 12:12 J Decker wrote: > On Thu, Nov 3, 2016 at 9:10 AM, Michał Wadas > wrote: > > Why you can't solve it with shared memory buffer? Shared - I mean

Re: Proposal of Multithread JavaScript

-level manipulation of shared data without requiring SharedArrayBuffers, a `malloc` reimplementation, and a boilerplatey abstraction on top of everything. - Isiah Meadows m...@isiahmeadows.com On Wed, Nov 2, 2016 at 8:27 PM, Michael J. Ryan <track...@gmail.com> wrote: > At the mod

Re: Proposal of Multithread JavaScript

I'll post it to the list when it's ready, though. On Wed, Nov 2, 2016, 16:27 Isiah Meadows <isiahmead...@gmail.com> wrote: > I've been working on another idea for parallelism that also leverage > modules, but doesn't involve workers. It will enable read-only resource > sharing o

Re: Proposal of Multithread JavaScript

I've been working on another idea for parallelism that also leverage modules, but doesn't involve workers. It will enable read-only resource sharing of direct object instances across threads, using realms, a built-in concept of thread ownership, and atomicity for ensuring thread safety. It also

Re: Conditional object properties

etting the properties to `value || null` instead of > extending the object with new properties imperatively. > > On Wednesday, November 2, 2016 12:38:05 PM CET Isiah Meadows wrote: > > What benefit would this bring over imperatively adding properties? > > > > On Wed, Nov 2,

Re: Conditional object properties

What benefit would this bring over imperatively adding properties? On Wed, Nov 2, 2016, 08:18 Luke Mitchell wrote: > Hi all, > > I often come across a situation where I wish to extend an object > (usually an argument for an API request) if a particular condition is > satisfied,

Re: Another statement expression-related proposal

g loops with the current `do` expression proposal (loops currently act like `reduce`, which is incredibly unintuitive). > On Wed, Nov 2, 2016 at 10:13 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > Yes, there's been a bit of talk about modifying the `do` proposal in > va

Another statement expression-related proposal

Yes, there's been a bit of talk about modifying the `do` proposal in various ways (like allowing more than a block, using `=` to differentiate, etc.), but each of these have potential ambiguities (like conflicting with `do-while` or object literal syntax, respectively), and give unintuitive

Re: Proposal: expression mode (=)

Beat you to it by about a year ;-) https://esdiscuss.org/topic/generalize-do-expressions-to-statements-in-general And to be quite honest, I did find it got some interest from TC39, but it was one of them IIRC that pointed out the ambiguity with `do { ... } while (...)`, in which the fix would

Re: Re: Proposal: expression mode (=)

I like the idea of expressions over statements (it's actually my preference), but not at the cost of breaking *everything* (feel free to fork Acorn/Escodegen and create your own transpiled JS variant - their licenses permit it), so my support of your particular idea is pretty much nil, at least in

Re: Re: Proposal: expression mode (=)

Not quite. I did some later thinking, and hage found probably a simpler solution. On Mon, Oct 31, 2016, 16:10 Yongxu Ren wrote: > Isiah, > The reason for `=` instead of the `do expression` is to write functional > code without extra syntax. I do not think there are any

Re: Standardize ES Worker

Inline. On Mon, Oct 31, 2016, 10:33 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 10/31/16 8:42 AM, Isiah Meadows wrote: > > When the worker has finished loading, so you can send and receive > messages > > OK, what about a worker that when it loads just starts and in

Re: Re: Proposal: expression mode (=)

For what it's worth, if the `=` requires a space before it (I disagree that the semantic ambiguity must exist at assignment - it could simply require whitespace), that alone would create sufficient context to differentiate. Compare these two: ```js a == {} // loose equals, almost always false a =

Re: Proposal: expression mode (=) (Caitlin Potter)

I'd have to agree that `=` just feels ugly and slightly wrong for this use case. On Sun, Oct 30, 2016, 22:05 Caitlin Potter wrote: > > > > On Oct 30, 2016, at 9:33 PM, David Baldwin < > david.chris.bald...@gmail.com> wrote: > > > > So just to clarify would the

Re: Standardize ES Worker

agree with your approach to avoid new global variable as much as possible. To respect this, how about `Channel#createChannel` method? ``` const [chan, remoteChan] = worker.createChannel() worker.send('newchan', remoteChan [remoteChan]) ``` 2016. 10. 28. 오전 7:18에 "Isiah Meadows" <isiahmead

Re: Standardize ES Worker

Inline On Thu, Oct 27, 2016, 21:42 Boris Zbarsky <bzbar...@mit.edu> wrote: > On 10/27/16 6:18 PM, Isiah Meadows wrote: > > 1. Add a new `import.fork(script): Promise` method-like > > expression that loads the worker and resolves when done/rejects if it > > couldn't for

Re: Standardize ES Worker

Here's my idea for a new API, leveraging ES modules and the proposed (stage 2) dynamic `import()` proposal. It also supports the shared memory proposal. 1. Add a new `import.fork(script): Promise` method-like expression that loads the worker and resolves when done/rejects if it couldn't for some

Re: Standardize ES Worker

Maybe with modification. I currently feel workers are a bit heavy (with their event driven nature), and they most definitely don't follow the idioms of the modern JavaScript language (very promise heavy). On Sun, Oct 23, 2016, 02:11 Park Hyeonu wrote: > Now we're about to

Re: expanding comments proposal

On Thu, Oct 20, 2016, 21:35 Isiah Meadows <isiahmead...@gmail.com> wrote: > Please, let's not add a new pragma to the language. `"use strict"` was a > hack to enable some sanity while still remaining back-compatible, but it's > not something we should repeat IMHO. (TC39

Re: expanding comments proposal

Please, let's not add a new pragma to the language. `"use strict"` was a hack to enable some sanity while still remaining back-compatible, but it's not something we should repeat IMHO. (TC39 unanimously I would, on the other hand, strongly support dropping most of the restriction in section 16,

Re: A Result class for functions that may return errors

. That's why I'm not sure how useful it could be as a language addition. > > > > > *From: *Isiah Meadows <isiahmead...@gmail.com> > *Sent: *18 October 2016 23:15 > *To: *Bruno Jouhier <bjouh...@gmail.com>; es-discuss@mozilla.org > *Subject: *Re: A Result class for

Re: A Result class for functions that may return errors

I agree with this: if a result may fail normally, I would just return a sentinel value like `undefined` (I usually avoid `null`). If it's truly exceptional, don't catch it except to log it/etc. On Tue, Oct 18, 2016, 17:49 Bruno Jouhier wrote: > try/catch is often

Re: Re: A Result class for functions that may return errors

I would also like to point out that V8 is one of few that don't optimize `try-catch`, and both Chakra and SpiderMonkey do optimize them IIRC (the latter has trouble optimizing functions that throw, though). On Tue, Oct 18, 2016, 15:29 Josh Tumath wrote: > > Not sure if

Re: Feature Request: Make ECMA262 a superset of JSON

Inline. On Tue, Oct 18, 2016, 12:01 Richard Gibson <richard.gib...@gmail.com> wrote: > On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > I'll point out that encoding and evaluating JSON literally can easily > become a potential securi

Re: Feature Request: Make ECMA262 a superset of JSON

Okay. I stand corrected (it was in fact `["__proto__"]` that actually evaluates to the property). ----- Isiah Meadows m...@isiahmeadows.com On Tue, Oct 18, 2016 at 9:58 AM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > Note that `["__proto__"]` is diff

Re: Existential Operator / Null Propagation Operator

On Thu, Oct 13, 2016, 12:07 Claude Pache wrote: Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit : >IIRC the proposed syntax for computed properties was x?.[y], Yes you’re right, sorry :/ IMO it still seems the syntax problem is the main

Re: Re: Existential Operator / Null Propagation Operator

It may be a good idea to create a pull request for it if it isn't listed yet (search "null propagation JavaScript"). I know there's a proposal written out (I've seen it), I just don't recall the exact URL offhand nor if there's a champion or not, but I thought it did. It could be one of those

Re: Re: Existential Operator / Null Propagation Operator

IIRC the proposed syntax for computed properties was `x?.[y]`, to avoid the ambiguity. On Thu, Oct 13, 2016, 10:24 Kagami Rosylight wrote: > > > >The token ?. works fine > > > > I think more than half of this thread is about syntactic ambiguity, > regardless of whether

Re: Re: Existential Operator / Null Propagation Operator

TypeScript can change if it has to, and it's done so before (ES modules are a good example of this). They try their best to be a strict superset of ECMAScript, and this even goes as far as making type errors early warnings, not early errors, by default (the latter would technically be a violation

Re: Support () => {}() syntax?

Yeah... A top level async `do` expression would be nice, but it doesn't cover conditional imports very well (especially when exported values depend on what's imported, which I've done before in CommonJS). On Sun, Oct 2, 2016, 14:31 Bradley Meck wrote: > To clarify top

Re: Syntax Proposal: Anonymous Arguments

I agree. Also, in particular, Scala's partial application syntax does tend to confuse newcomers, and can easily border on the same obfuscation level as point free style in Haskell for similar reasons (which is easier to understand, `owl = (.) . (.)` or `owl f g x y = f (g x y)`). Also, I'm not

Re: Make things like Reflect an import instead of a global?

I don't believe there's a formal proposal yet, but there definitely should be. It's been discussed frequently for years by the standards leaders; it's just that we're 1. still waiting on a loader spec for modules to complete (the WHATWG spec is still a work in progress, with quite a bit of recent

Re: Proposal: anaphoric if and while syntax

I say let's hold off until JavaScript gets pattern matching support (assuming it does). It's rather limiting otherwise, and the use case IMHO doesn't really merit a new syntax for it. On Thu, Sep 15, 2016, 15:47 Jeremy Martin wrote: > > If yes ... why would anyone write that

Re: Function composition syntax

My function composition strawman is now live: https://gist.github.com/isiahmeadows/7b5b49469c08bd3ddc425d15b0bd65c8 Sorry for the wait! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Function composition syntax

ht help backing up my above opinion. > - "sandwich pattern in javascript code" > > http://stackoverflow.com/questions/11371993/sandwich-pattern-in-javascript-code/27649488#27649488 The sandwich pattern has little to do with composition, if any. I'm not fully convinced you actually u

Re: Function composition syntax

Oh, and most of your concerns will be addressed in some way in the completed strawman. On Thu, Sep 8, 2016, 14:59 Mike Samuel <mikesam...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 1:54 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > Someh

Re: Function composition syntax

can find any traces other than potentially suspicious mic activity, and the fact this is on a stock, non-rooted phone kept fully up to date). Sorry for the delay! :'( On Thu, Sep 8, 2016, 14:59 Mike Samuel <mikesam...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 1:54 PM, Isiah Meadows &

Fwd: Function composition syntax

Somehow, this missed the list... -- Forwarded message - From: Isiah Meadows <impinb...@gmail.com> Date: Wed, Sep 7, 2016, 12:03 Subject: Re: Function composition syntax To: <mikesam...@gmail.com>, <es-discuss@mozilla.org> I was thinking in reverse order, b

Re: Function composition syntax

Inline. On Wed, Sep 7, 2016, 11:05 Mike Samuel <mikesam...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 10:10 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > > I would like to see a function composition operator make it into the > > language. Currently, there

Re: Function composition syntax

Inline. On Wed, Sep 7, 2016, 10:44 Bergi wrote: > Hi, > interesting proposal! > > > Here's what I propose: a new infix operator `>=>` (operator and direction > > can change) for composing two functions. > > Sweet, reminds me of Kleisli composition in Haskell > >

Function composition syntax

I would like to see a function composition operator make it into the language. Currently, there is: - Lodash: `_.flow` and `_.flowRight` (lodash/fp alias: `_.compose` and `_.composeRight`) - Underscore: `_.compose` - Ramda: `R.compose` - Tons of npm modules:

Re: Extended dot notation (pick notation) proposal

ot like the alternatives are much larger: `x => x.property` (and for the original proposal's shorthand: `(...xs) => console.log(...xs)`). > On Tue, Sep 6, 2016 at 8:54 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> I'll note that the type checking part will even

Re: Re: ES8 Proposal: Optional Static Typing

I'm just an observer who occasionally contributes to this list, but I don't see static types making it into ES any time soon. First, no type checker (TypeScript, Flow, or any other) can fully check the core language (most notably `bind`, `apply`, `call`, and `Object.assign`). Second, they both

Re: Reflect.hasOwn

I'll admit I use them partially out of laziness and partially because engines already optimize for this much better than with actual maps (only string keys). I frequently alias `const hasOwn = Object.prototype.hasOwnProperty`, so this wouldn't do much for me other than saving a declaration in each

Re: Extended dot notation (pick notation) proposal

gt; [image: Inline image 1] > > On Tue, Sep 6, 2016 at 6:49 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> > Isiah's workaround works but has the unfortunate side affect of copying >> values / increasing reference counts to objects. I'd love to see a built

Re: Extended dot notation (pick notation) proposal

clean up the > references. Making the developer do it? In my experience good luck . > Naturally it won't likely matter much unless it's hanging onto a DOM > element or some extent resource but still. > > On Sep 6, 2016 6:19 AM, "Isiah Meadows" <isiahmead...@gmail.com>

Re: Extended dot notation (pick notation) proposal

t in > solution. > > On Mon, Sep 5, 2016 at 2:38 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> TypeScript has a fair number of proposals aiming to address this (things >> like difference types, partial types, etc.), but in general, I find it just >&g

Re: Extended dot notation (pick notation) proposal

TypeScript has a fair number of proposals aiming to address this (things like difference types, partial types, etc.), but in general, I find it just as easy to do it this way (which is easily checked): ```js const {toDate, fromDate, location, flavor} = this.state; const goodKeys = {toDate,

Re: Proxies and preventExtensions: how to avoid inconsistency in a membrane?

Is a proxy a valid proxy target? If that's the case, then the indirection should allow you to do what you're doing. The outer proxy could freeze and let the inner proxy know it shouldn't extend anything anymore, without actually freezing it. The inner proxy can handle the rest of the actual logic

Re: Ignoring arguments

If you're talking about ignored function parameters in a declaration or expression, much like `_` in several functional languages (like Haskell and Scala), I could see value in that. I'd prefer an explicit token for that, though, something like this: ```js // ImmutableJS: convert map to list,

Re: How to solve this basic ES6-module circular dependency problem?

and initialize that crap when it's being > declared. > > That's what I thought at first too, but it's not the case, and I'm trying > to find a solution. > > */#!/*JoePea > > On Wed, Aug 10, 2016 at 2:41 AM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >>

Re: Ignoring arguments

Okay. I'll admit I'm wrong here. I misremembered. I knew they were more of a legacy thing, I just didn't know they were available in strict mode. On Wed, Aug 10, 2016, 05:37 Claude Pache <claude.pa...@gmail.com> wrote: > Le 10 août 2016 à 11:01, Isiah Meadows <isiahmead...@gmail.

Re: How to solve this basic ES6-module circular dependency problem?

First of all, I'll point out that even if it's an internal API, you should just initialize them immediately. You already have an otherwise fully initialized C, so you should just add them whenever it comes. You shouldn't need a `setUpA` export, especially called by one of its dependencies. Just

Re: Function constants for Identity and No-op

I'll note that it's longer than just typing them out manually (and close if they're aliased): ```js Function.IDENTITY IDENTITY x => x Function.NOOP NOOP () => {} ``` Not sure if it adds anything. On Tue, Aug 9, 2016, 14:44 Eli Perelman wrote: > I'm not sure if something

Re: Ignoring arguments

For what it's worth, elided array elements aren't available in strict mode (they're a syntax error), and it's not likely anyone is going to want to add a new sloppy mode only feature. Plus, it's not easy to tell at a glance if it's a typo or intentional. `Math.min(x,,y)` is a likely error, but a

Re: Proposal: Splitting the "Standard Library" from the EcmaScript spec

@Kris What about `import {apply} from "@std:reflect"`? (totally not my original idea) On Thu, Jul 28, 2016, 13:45 Kris Siegel wrote: > I love this idea. I was originally hoping to champion a whole slew of > additions to the JavaScript Standard Library because I'd really

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

You could also solve the iterability this way with weak references: ```js function *iter(wm) { for (const ref of wm._refs) { const key = ref.get() yield [key, wm.get(key)] } } function remove({wm, ref}) { wm._refs.remove(ref) } class IterableWeakMap extends WeakMap {

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

Could you explain a real world use case for this? I recall some that it would've simplified some, but the best implementation often didn't even require iteration, but just changing the data layout altogether. On Wed, Jul 13, 2016, 08:13 Michael Kriegel wrote: >

Re: Typed Objects and Classes

Descriptors are annoying to deal with, anyways IMO. If it had a corresponding syntax, and if you could use functions/object prototypes to type them, they might have had a little better traction, but here's my opinion: anything type-wise that can change at runtime (like the descriptor proposal)

Re: Typed Objects and Classes

For what it's worth, engines already optimize for static object layouts. So if you never change the property set for instances of that class, the struct won't help performance much in practice. Similarly, standard arrays with just numbers are almost as fast as typed arrays as well, so unless

Re: Has there been any discussions around standardizing socket or file io usage?

For server-side, you might want to look into the CommonJS standards, which Node itself was based on from its conception. There's the file system API, the console API (different from browsers), the event emitter API, the module standard (which Node purely extended) and even the precursor to

Re: A plan to help TC39 become more open up to community contributions and participations

Didn't know that. Nice to know! :-) On Wed, Jun 15, 2016, 11:48 Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Jun 14, 2016, at 8:57 PM, Isiah Meadows <isiahmead...@gmail.com> wrote: > > Just an educated guess (I'm not actually involved in any part of this

Re: A plan to help TC39 become more open up to community contributions and participations

Just an educated guess (I'm not actually involved in any part of this effort - just a random person subscribed to this list), but I think it's because of ECMA itself. Granted, TC39 has already noted that this one doesn't exactly fit well with the rest of their framework, because of the constant

Re: Array.prototype.includesAll

I agree that the tone was a bit iffy, but I do support this being in a third party library. I have only a couple times ever had a legitimate need for this, one of which was to write an assertion that I later used. Not sure it's common enough it needs to be in the language. I just don't see the

Re: Oddly accepted RegExps

Thanks! I wasn't able to glean that from the spec. It is admittedly confusing and not very obvious, but I was just curious. On Fri, Jun 3, 2016, 16:41 Claude Pache <claude.pa...@gmail.com> wrote: > > > Le 3 juin 2016 à 10:20, Isiah Meadows <isiahmead...@gmail.com> a écrit

Oddly accepted RegExps

These three RegExps don't appear valid, even after reading the Annex B, but they do behave consistently in both Chrome and Firefox. They are listed here with equivalent regexps: - `/[[]/` -> `/\[\[\]/` - `/[]]/` -> `/(?!)/` (i.e. nothing) - `/a{,,/` -> `/a\{,,+/` Is this a spec bug or an

Re: Error-Type Specific try/catch Blocks

Shiny... On Fri, May 27, 2016, 05:06 Arthur Stolyar wrote: > Something wrong with prev link. > https://github.com/zenparsing/es-typed-catch > On May 27, 2016 12:00, "Arthur Stolyar" wrote: > >> If something, here seems to be another similar

Re: Suggestion: "Object.hasOwnProperty"

I'd, for ergonomic reasons, would prefer it on Reflect. I very frequently alias this function, so having it as a static method on Reflect would be nice. On Thu, May 26, 2016, 17:42 doodad-js Admin wrote: > >> This would break a Web, a I have seen code that relies on >

Re: es-discuss Digest, Vol 111, Issue 83

Try sending it with `unsubscribe` as the subject and no text. Or you could always go to the link and do it from there. ;-) On Thu, May 26, 2016, 16:28 Will wrote: > unsubscribe > > On Thu, May 26, 2016 at 4:21 PM, wrote: > >> Send es-discuss

Re: How about a "named true" and a "named true property"

Is defining a variable set to true not sufficient? On Thu, May 26, 2016, 05:02 Gray Zhang wrote: > I don't really know how to name this feature, but I find it quite > neccessary > > In JavaScript land there are many functions with parameters of type > boolean, and

Re: Observing whether a function is strict

I would be mostly okay if sloppy mode goes away. The only use case I have now for it is for accessing the global in a platform independent manner, but the System.global proposal eliminates this need. I write all code in strict mode now, so I only see likely performance benefits from completely

Re: Proposal: importing selected chucks of a module into an object

Even with some larger libraries, you can do things like this: ```js // small modules import xmlParse from 'xml/parse'; import xmlCreate from 'xml/create'; import xmlSandwich from 'xml/sandwich'; import jsonParse from 'json/parse'; import jsonCreate from 'json/create'; import jsonBacon from

Re: operator overloading proposal

usage. > On May 20, 2016 7:44 PM, "Isiah Meadows" <isiahmead...@gmail.com> wrote: > > Maybe, maybe not - it largely depends on how TypeScript and ES end up > converging, and how the efforts for strong typing (like floats, longs, > structs, etc.) end up. Also, TypeSc

Re: Existential Operator / Null Propagation Operator

I'm aware it's specified as a cover grammar, which is the easiest way I'm aware of to do it in a traditional declarative grammar. If you're writing a parser, though, you'll probably be using a mixture of lookahead and speculative parsing, or something to that effect, in practice, since it's

Re: operator overloading proposal

n definitely wait on this. > > Definitely looking forward to static typing. Is > https://github.com/sirisian/ecmascript-types the proposal to be following? > > On Thu, May 19, 2016 at 12:35 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> That is a valid con

Re: Existential Operator / Null Propagation Operator

I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions. ```js foo((a, {b}) => b) foo((a, {b}) <= b) ``` Also, that proposal is not syntactically ambiguous, since numbers are not allowed to start an identifier. On

Re: Get currently destructured object

How is it any different than this, to borrow your first example: ```js function foo(baz) { const {bar} = baz // do things } ``` On Thu, May 19, 2016, 11:59 Michał Wadas wrote: > Idea: > > function foo({bar, *: baz}) { > > } > > would be equivalent to: > >

Re: operator overloading proposal

) >> } >> >> operator+= (x: Vec2, y: Vec2) { >> x.x += y.x >> x.y += y.y >> } >> >> operator+= (x: Vec2, y: number) { >> x.x += y >> x.y += y >> } >> >> // #number

Re: String concatination without +

They don't trim the leading indent, but that's easy enough to implement in a template tag. On Tue, May 17, 2016, 12:39 kdex wrote: > No one says you have to use the "+" operator. Why don't you use template > literals? > > On Dienstag, 17. Mai 2016 16:35:28 CEST Cedric neuland

Re: Error-Type Specific try/catch Blocks

is is just yet another highly requested feature that somehow > ended up in a deadlock then got buried into the deep... > > > > > On Tuesday, May 17, 2016, Isiah Meadows <isiahmead...@gmail.com> wrote: > >> Pattern matching has been considered before, and the performanc

Re: Error-Type Specific try/catch Blocks

Pattern matching has been considered before, and the performance will suck if you consider things like `Point(x, y)`. It's very hard to optimize at runtime, and engines don't have time to optimize that statically. If you want to consider Clojure as an example of one that does this dynamically, it

Re: operator overloading proposal

want to create instance of `Complex` with plain old numbers or I > might want to use `BigNumber` instances. > Without operator overloading this means that I would have add methods to > `Number.prototype` or wrap each number > in an object with methods. Neither of which are particular appe

Re: "Super" hoisting

ng brittle or spaghetti code -- and is subject to sudden changes if > > someday an engine decides to do GC in a different way, being clever could > > suddenly turn against you. > > > > [>] Brian > > > > On 5/13/2016 1:45 PM, Isiah Meadows wrote: > >>

Re: "Super" hoisting

I think the original problem that caused this discussion with GC could be solved with just a weak map: ``` // Original class thing { doSomething(x, y) { let a = x + y; let b = ay; let c = bx; return (c); } } // With a weak map const wm = new WeakMap()

Re: introduction of statefull functions (inspired by Scala language) - advanced specification of "operator()" for arbitrary objects

I would like to point out that this particular example could be done in terms of existing proxies now: ```js var sttFunc = new Proxy({}, { get(target, key) { console.log("get: [", key, "]"); return key; }, set(target, key, value) { console.log("set: [", key, "]

Re: Re: Tracking proposals should be standardized with issues

Here's my concerns: 1. People are going to blow up the issues they like, instead of either creating issues in those related repos or finding more appropriate channels for them. 2. People are going to start filling issues for whatever proposal they came up with, without really deliberating over

Re: operator overloading proposal

; But, do we really need operator overloading? A method can be used instead, > I think. > > 2016-05-11 8:53 GMT+02:00 Isiah Meadows <isiahmead...@gmail.com>: > >> Efficiency and optimization. If you're stupid enough to want to violate >> those priorities in a public AP

Re: operator overloading proposal

y equivalent to `a = a + b`, `a *= b` not > equivalent to `a = a * b`, etc? I'm quite confident that any proposal that > allowed for that would get tons of pushback. > > On Tue, May 10, 2016 at 11:26 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> 1. Yes, they wo

Re: operator overloading proposal

tic. My hope is to > eventually use static typing (flow b/c I'm using babel) to remove the > lookup cost. > > > On Tue, May 10, 2016 at 7:07 PM, Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> You're correct in that the operator doesn't do any type check

Re: operator overloading proposal

> a single `operator +(...args) {}` > definition. But then again, something like `Function.defineOperator` seems > cleaner and suggests implicit > (optional?) type checks with its second argument. > > On Dienstag, 10. Mai 2016 15:25:32 CEST Isiah Meadows wrote: > > Here's my though

Re: operator overloading proposal

> For all I know, += might be doing such anyway in some engines, but for > my stuff which is a lot of 3D math that could be a performance killer. > It would be nice to be able to just add points and such, as long as the > overhead is negligible. > > [>] Brian > > On

Re: Proposing a conditional assignment (or equals) operator

Thought I'd mention this has been discussed before: - https://esdiscuss.org/topic/existential-operator-null-propagation-operator - https://esdiscuss.org/topic/the-existential-operator - https://esdiscuss.org/topic/optional-chaining-aka-existential-operator-null-propagation -

Re: operator overloading proposal

I would prefer syntax + internal slots, since you'll know at creation time whether the object has overloaded operators. It's much simpler for the engine to figure out, and it's more performant because you only need to check one thing instead of worrying about inheritance, own properties, etc.

Re: Is `undefined` garabage collectable?

I'll just point this out: low level optimization like that is very unintuitive. Game engines often use object pools to avoid allocation and GC, since even a single `malloc` is sometimes too expensive. There's other ways of reducing GC as well, such as persistence (like persistent data structures

Re: Promise based Observable proposal

Probably best to first see how people react here: https://github.com/zenparsing/es-observable You also might appreciate the async generator/iterator proposal here: https://github.com/tc39/proposal-async-iteration (Note: observables push directly to iterators and are event based, while async

Re: Proposal: Switch position of delay and callback in signature of `setTimeout()`

If it makes it into the language, I'd rather see `Function.delay(timeout, callback)` or, even better, `Promise.delay(timeout).then(callback)`. The latter would also fit better with modern ES standard language APIs, IMHO. The latter has already been suggested here before, plenty of times, but

Re: Function#toString revision: JSDoc comments?

I don't like the idea of including preceding comments in `Function.prototype.toString` itself on grounds it's harder to parse for other related reasons. As for anything including preceding comments, I'd be happy with something somewhat independent, as long as it's not requiring JSDoc to be

Re: Take let variable out of temporal dead zone

Try `window.foo`. That's usually what's done within global IIFEs, which has similar scope restrictions. On Fri, Apr 15, 2016, 13:52 Oriol Bugzilla wrote: > Consider this code: > ```html > > let {foo} = null; // TypeError > > > // Here I want to assign some some

Re: stable sort proposal

How about an `Array.prototype.stableSort(comparator?)` method? Several languages already have something like this, anyways. (Speaking of bugs related to unstable sorts, my blog has that problem as well - unstable sort resulting in incorrect order.) On Wed, Mar 16, 2016, 18:50 Tab Atkins Jr.

Re: stable sort proposal

I'm mostly neutral on this, other than that a stable sort API should exist, and it shouldn't involve changing how the first argument of `Array.prototype.sort` is processed. On Thu, Mar 17, 2016, 22:20 Bergi <a.d.be...@web.de> wrote: > Isiah Meadows wrote: > > > A po

<    2   3   4   5   6   7   8   9   10   >