Re: Yet another attempt at typed JS data

At some point in the algorithm of [Array.from], the newly-created array will indeed be created as sparse (at steps 9/10), but this is usually not observable (that is, unless you are creating an instance of a subclass of Array with very unusual behaviour) as far as the spec is concerned (optimisa

Re: Array.prototype.toggle

> Le 7 févr. 2020 à 14:52, Claude Pache a écrit : > > > >> Le 7 févr. 2020 à 13:23, manuelbarzi > <mailto:manuelba...@gmail.com>> a écrit : >> >> calling it again would just apply the same mechanism => "do this element >> already exis

Re: Array.prototype.toggle

> Le 7 févr. 2020 à 13:23, manuelbarzi a écrit : > > calling it again would just apply the same mechanism => "do this element > already exist? "remove it" : "add it". in the example, it would just add 1 at > the end of array (i.e. just a push), calling it the second time. Probably `Array.pro

Re: syntax for case ranges

Try typing `3 < 2 < 1` in the web console of your favourite browser, and see the result: it will evaluate to `true`. No, your browser isn’t buggy, it is just following blindly the semantics of `<`. Modifying the meaning of `3 < 2 < 1` in order to make it evaluating to `false` is a BC break. Is

Re: Proposal: strict built-in functions

> Le 8 déc. 2019 à 15:39, Mark S. Miller a écrit : > > Wow, Edge is definitely in violation of the intent of the spec, and the > intent of the history of treatments of .caller in previous discussions and > specs over the years. The Edge behavior is grossly unsafe. > > Hi Jack, thanks for cat

Re: Proposal: strict built-in functions

t;https://tc39.es/ecma262/#sec-forbidden-extensions> [gh-issue 562]: https://github.com/tc39/ecma262/issues/562 <https://github.com/tc39/ecma262/issues/562> —Claude > > On Mon, Dec 9, 2019, 1:12 AM Claude Pache <mailto:claude.pa...@gmail.com>> wrote: > > >> Le 8

Re: Proposal: strict built-in functions

>> Le 8 déc. 2019 à 14:43, Jack Works a écrit : >  > In the current spec, strictness of the built-in functions are > implementation-dependent behaviors. This proposal is going to fix this > problem. > https://github.com/Jack-Works/proposal-strict-built-in-functions > Hi, See https://github

Re: Can we improve async JavaScript error handling?

> Le 29 nov. 2019 à 21:05, Lars Eidnes a écrit : > > > > 1) Is it a good idea to introduce an alternative to setTimeout, where the > distinction is that it returns a Promise, and that return/throw in the > callback take the role of resolve/reject? I think so (although there is no need keep

Re: Ternary operator enhancement proposal

> Le 13 nov. 2019 à 03:43, devlato a écrit : > > Hey folks, > > not sure if you haven't discussed something similar, but what do you think > about making an enhancement for the ternary operator, to make it more > powerful? > I've created a small explanatory doc on GitHub: > https://github.

Re: Optional chaining syntax but with the "mice" operator ?

> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura > a écrit : > > Doesn't that bring risks to breaking the web? > > You seen, many, MANY servers running php have the "shot-tags" feature > enabled, in which pages with will be interpreted. > In this case, any html page with embedded scrip

Re: Optional chaining syntax but with the "mice" operator ?

> Le 5 sept. 2019 à 23:39, Andrea Giammarchi a > écrit : > > This is basically a solution to a common problem we have these days, where > modules published in the wild might have a `default` property, to support ESM > logic, or not. > > ```js > // current optional chaining logic > const imp

Re: Async Class

> Le 26 août 2019 à 17:11, Dimitrian Nine a écrit : > > Class is just function constructor that return object Although in JS a class is represented by the same object as its constructor, I don’t think it is good to assimilate the concept of JS class and JS constructor. Indeed, a class consis

Re: Modulo Operator %%

> Le 12 août 2019 à 22:00, Matthew Morgan a écrit : > > JS needs a modulo operator. It currently has the remainder operator `%` which > works in most cases except for negative values. I believe the the `%%` would > work great and be easy to remember. > > let x = (-13) %% 64; > is equivalent

Re: Proposal: `String.prototype.codePointCount`

> Le 8 août 2019 à 11:07, fanerge a écrit : > > There are many such requirements in a real development scenario, such as how > many characters are allowed to be entered by the user, which is something we > should consider not in Unicode for Basic Multilingual Plane. I have cases where I want

Re: Proposal: `String.prototype.codePointCount`

> Le 8 août 2019 à 04:37, fanerge a écrit : > > I expect to be able to add an attribute to String.prototype that returns the > number of codePoints of the string to reflect the actual number of characters > instead of the code unit. Note however that “the number of code points” is not the same

Re: Removing the space in `a+ +b`?

> Le 28 juin 2019 à 19:03, guest271314 a écrit : > > Reversing the order does not require a space character > > ``` > +b+a > ``` If you have `+a + +b`, reversing order is not interesting. But more importantly, there is no point into searching for a solution unless there is a problem. What

Re: Removing the space in `a+ +b`?

> Le 28 juin 2019 à 17:41, Isiah Meadows a écrit : > > Currently, the production `a+ +b` requires a space to disambiguate it from > the increment operator. However, `a++b` is not itself valid, as the postfix > increment cannot be immediately followed by a bare identifier on the same > line, n

Re: Proposal: Exposing native scroll as API

> Le 21 juin 2019 à 16:07, Adam Eisenreich a écrit : > > Hello everyone. I think browsers should expose the native scroll as API. > > Possible uses: > * Native-like scroll in canvas apps (games) - Google's Proxx > (https://proxx.app/) had to do quite a bit of magic to have native scroll for

Re: Proposal: Symbol.inObject well-known symbol to customize the "in" operator's behavior

> Le 9 mai 2019 à 23:17, Tom Barrasso a écrit : > > If this Symbol were seriously considered I believe it would expand the > meaning of the in operator as you’re correct, this is definitely not it’s > current intention. > The `in` operator has a well-defined meaning, that by design you can

Re: Proposal: Symbol.inObject well-known symbol to customize the "in" operator's behavior

> Le 9 mai 2019 à 20:52, Tom Barrasso a écrit : > > Like Symbol.hasInstance but for the "in" operator. > This symbol would work for both native and user-defined objects. > > *Example implementation* prototyping native object: > > ```js > String.prototype[Symbol.inObject] = > function(search

Re: Proposal: Static Typing

> Le 27 mars 2019 à 18:26, Michael Theriot a > écrit : > > Would an error at runtime or compiletime occur here? > The check cannot be reliably done at compile time in general; it must be a runtime check. (Tools may provide partial static analysis, but that’s an extra.) The simplest reason

Re: Dash-case keys

> Le 29 janv. 2019 à 08:45, Sultan Tarimo a écrit : > > That is obj.font-size would rightly be invalid. Sadly, `obj.font-size` is *not* invalid, it has some well-defined semantics. That would be a source of bugs —Claude___ es-discuss mailing list

Re: Proposal: Class Templates

> Le 16 janv. 2019 à 13:57, ViliusCreator a écrit > : > > “Strongly typed” Strongly typed is not Statically typed. Python is strongly > typed for example. Strongly typed language means that `”something” + 1` will > throw error, Weakly typed means that `”something” + 1` will turn `1` into >

Re: Proposal: Class Templates

From what I understand (that is, not much), class templates are useful in strongly typed languages, so that one can have a family of classes that share the same implementation but that derive from different types; e.g. Stack for stacks of ints and Stack for stacks of strings. In JS, you can have

Re: Proposal: Placeholder operator

> Le 11 janv. 2019 à 14:02, Sultan a écrit : > > Placeholder operator: ! > > Use in function parameters(maintains arity without creating a named binding): > > const foo = (a, b, !) => {} Today, you can write: ```js const foo = (a, b, _) => { } ``` Is the complexity added to the language wo

Re: String identity template tag

Random suggestions: * `String.cooked`, which pairs well with already existing `String.raw` * `String.vanilla` * `String.plain` * `null`, i.e., using a null (or undefined) value as tag before a template literal is equivalent to using no tag. (Con: not polyfillable) —Claude __

Re: New: proposal-safe-prototype

Sorry, I didn’t read the thread thoroughly (so maybe I’ll repeat someone). But here are some serious issues with your proposal: -- 1. Assignment of properties deep in the object hierarchy split in two instructions: ```js var a = { __proto__: { foo: { bar: 2 } } } with safe-prototype; var

Re: New Proposal: Placeholder syntax

> Le 28 nov. 2018 à 19:17, Andrew Kaiser a écrit : > > Hi all, > > I have created a short proposal to introduce syntactic sugar for anonymous > functions in a 'scala-like' manner, linked here > https://github.com/andykais/proposal-placeholder-syntax >

Re: Proposal for faster this assignments in constructor functions

> Le 28 nov. 2018 à 19:32, Simo Costa a écrit : > > In costructor functions and in the constructor() method in ES6 classes is > easily to fall in the following pattern: > > F(par1, par2, ..., parN) { > this.par1 = par1; > this.par2 = par2; > ... > this.parN = parN; > } > > So my propo

Re: Expectations around line ending behavior for U+2028 and U+2029

> > Would it be worth exploring a definition of U+2028/29 in the spec such that > they behave as line terminators for ASI, but otherwise do not increment > things line number counts and behave as whitespace characters? Diverging the definition of line terminator for the purpose of line counti

Re: Expectations around line ending behavior for U+2028 and U+2029

> Le 24 oct. 2018 à 21:58, Logan Smyth a écrit : > > On the other hand, it seems like every editor that I've looked at so far will > not render these characters as newlines, I have just tried to open a file containing U+2028 and U+2029 in four different text editors / integrated environments

Re: Array.prototype.remove(item)

> Le 10 oct. 2018 à 23:17, kai zhu a écrit : > > hi Man, i don’t have strong opinion on Array.prototype.remove, but i have > strong opinion against your use-case to subclass/extend Array. from a > product-development perspective, you're creating unnecessary > integration-headaches by having

Re: Array.prototype.remove(item)

For that specific example, I think that a Set is more appropriate: ``` js export class Selector { private _set = new Set; get values(): ReadonlyArray { return Array.from(this._set); // although it might be better to return an iterator: return this._set.values(); }

Re: Object.assign interaction with __proto__ field.

> Le 26 sept. 2018 à 16:27, Mike Samuel a écrit : > > Might it be a spec bug that in the below, o's prototype changes, and o.x !== > b.x? > > const a = makeIntercepter(); > const b = { x: 1 }; > const o = Object.assign( > {}, > a, > b); > > console.log(`o is plain Object: ${ Object.get

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

> Le 9 sept. 2018 à 23:49, Isiah Meadows a écrit : > > Does `return foo` not seemingly imply the implicit unwrapping is > occuring *inside* the function? For me, no. If I want to await the resolution of the promise `foo` before handling the `catch` or the `finally` block, I expect to add an e

Re: __line_number__ and __filename__

> Le 24 août 2018 à 05:55, J Decker a écrit : > > On Thu, Aug 23, 2018 at 5:26 PM Aaron Gray > wrote: > I am debugging existing code that I have modularized, and am class'izing that > has unittests and it just would have been very useful to have this facilit

Re: let-in if do-expr is problematic? (was: Re: proposal: let in if parentheses)

> Le 21 août 2018 à 21:20, Herbert Vojčík a écrit : > > Hi! > > It would be nice to know if do expressions have some a chance, otherwise some > other syntax for let-in would be really helpful, especially now that we have > arrow functions. > > I would propose to use different variant of let

Re: proposal: String.prototype.padCenter

```js x.padStart((x.length + 32)/2).padEnd(32) ``` (BTW, I don’t like this habit of top-posting the reply. Please look below for the question I’m answering, and read the mail backwards for more context.) —Claude > Le 22 août 2018 à 05:47, Naveen Chawla a écrit : > > How would you combine padS

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 05:07, Claude Pache a écrit : > > > >> Le 5 août 2018 à 04:50, Claude Pache > <mailto:claude.pa...@gmail.com>> a écrit : >> >> >> >>> Le 5 août 2018 à 01:43, Michael Theriot >> <mailto:michael.lee.ther...

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 04:50, Claude Pache a écrit : > > > >> Le 5 août 2018 à 01:43, Michael Theriot > <mailto:michael.lee.ther...@gmail.com>> a écrit : >> >> Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and >> only if

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 01:43, Michael Theriot a > écrit : > > Try `Number.prototype.valueOf.call(obj)`: it will throw a TypeError if and > only if `obj` has no [[NumberData]] internal slot. Ditto for String, Boolean > and Symbol. > > I already mention this and demonstrate why it is not sufficie

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 04:14, Darien Valentine a écrit : > > > However it is ultimately not possible to replicate because there is no > possible brand test for [[BooleanData]]. Per spec, checking whether `Boolean.prototype.valueOf.call(obj)` throws will test whether an object has [[BooleanData]

Re: Implementing an identical JSON.stringify

> Le 5 août 2018 à 00:16, Michael Theriot a > écrit : > > `JSON.stringify` has unintuitive behavior regarding interal slots. I don’t think that anything involving an object that has a [[StringData]] internal slot but has `Number.prototype` in its prototype chain could have an ”intuitive” be

Re: Question: HTTPS everywhere...problem

> Le 4 août 2018 à 22:22, Felipe Nascimento de Moura a > écrit : > > I know of (and I also support) the HTTPS everywhere campaign. > I don’t think that ECMAScript has any feature related to the http protocol, or that make a distinction between secure and non-secure contexts. Wrong mailing l

Re: const {resolve} = Promise; // fails

> Le 19 juil. 2018 à 16:32, Andrea Giammarchi a > écrit : > > I know it's about subclassing, which is why I've asked why, once there's no > context, the default/base one is not considered, but since everyone came back > with the subclassing issue, which is actually what I've said myself on

Re: const {resolve} = Promise; // fails

> Le 19 juil. 2018 à 13:56, Andrea Giammarchi a > écrit : > > > Compared to every other public static method in ECMAScript that works, > including those methods that might need the contextual class, as it is for > the Array.from case. > > ```js > const {from} = Array; > > from({0: 'abc',

Re: Proposal: Static sort method on Array

> Le 7 avr. 2018 à 21:59, Rob Ede a écrit : > > I don't like the fact the only way to sort is in-place with Array#sort and I > can't be the first to feel this way or wonder why there isn't a built-in > solution. > > Obviously, searching "javascript array.sort" doesn't produce any helpful >

Re: Array.prototype.repeat

> Le 25 mars 2018 à 20:27, Cyril Auburtin a écrit : > > String and Array share a few methods. > > I think `repeat` could exist for Array as well > > At the moment are other more verbose ways to do so: > > - `Array.from({length: n}, () => 'foo')` > - `Array(n).fill('foo')` > - `[].concat(...A

Re: Allow Object Destructoring when assigning

> Le 22 mars 2018 à 20:51, Sebastian Malton a écrit : > > Currently object destructoring is only allowed during variable declaration, > however it would be useful, and seems rather odd from a usage standpoint, > that it cannot be done during assignment. > > Example: > This is a allowed: > `

Re: add reverse() method to strings

> > The only reason I would defend the "reverse" method in strings is because it > makes sense. > I think JavaScript is very intuitive, and, as Arrays do have the "reverse" > method, that simply makes sense to have it in strings as well. > ”Making sense” and ”symmetry of API” is not a suffic

Re: add reverse() method to strings

> Le 17 mars 2018 à 19:29, Oriol _ a écrit : > > Be aware your code breaks pair surrogates, which might be undesirable: > > ```js > var str = "a_\uD83D\uDE80_b"; > str.split("").reverse().join(""); // "b_\uDE80\uD83D_a" :( > [...str].reverse().join(""); // "b_\uD83D\uDE80_a" :) > ``` > >

Re: try/catch/else

> Le 9 févr. 2018 à 00:19, Peter van der Zee a écrit : > >>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache >>> wrote: >>>> >>>> What about the following pattern (labelled block + break)? >>>> >>>> ```js >>>>

Re: try/catch/else

What about the following pattern (labelled block + break)? ```js processSuggestions: { let suggestions; try { suggestions = await fetchSuggestions(); } catch (e) { alert('Failed to load suggestions'); break processSuggestions; } showSuggestions(suggestions); }

Re: ASI edits

eadows.com <http://www.isiahmeadows.com/> > > > On Sat, Jan 13, 2018 at 9:54 AM, Claude Pache <mailto:claude.pa...@gmail.com>> wrote: >> >> >> Le 12 janv. 2018 à 22:09, Isiah Meadows a écrit : >> >> I know this is probably bad timing (consid

Re: ASI edits

> Le 12 janv. 2018 à 22:09, Isiah Meadows a écrit : > > I know this is probably bad timing (considering [this PR][1] and the > fallout that followed), but I was thinking that it'd be nice if we > could insert a `[no LineTerminator here]` clause in a few places, to > remove some of the ASI hazar

Re: Looking for Champion: Null Coalescing (??) and Null Conditional Member Access (?.) operators

There are already official proposals for those. See: https://github.com/tc39/proposals and search for “Nullish coalescing Operator” for the first of your suggestions and “Optional Chaining” for the second one. —Claude > Le 20 déc. 2017 à 09:03, Arash Motam

Re: Allow any quoted string to be multiline?

> Le 17 déc. 2017 à 22:03, J Decker a écrit : > > I do see there are work-arounds (similar as using a hammer to put in a screw) > > I don't see a reason for why not allow multiline strings for other quote > types. I know... because people want more errors and to have their hand held > to id

Re: es-discuss Digest, Vol 130, Issue 41

> Le 16 déc. 2017 à 07:10, zhaoshche a écrit : > > Who can tell me what is it? > Why always send to me? > How to undescribe it? Your e-mail address is most probably subscribed to the es-discuss mailing list. Instructions to unsubscribe is found at the bottom of this page: https://mail.mozill

Re: How it feels to learn JavaScript in 2016

> Le 25 nov. 2017 à 16:03, kai zhu a écrit : > > i disagree. you can write more maintainable and cleaner code with the > premise typeof's will never change again (and give a one-time pass for > symbols), instead of over-engineered paranoid code that it *may* > change again in the future. > It

Re: Make comma at the end of line optional

> Le 12 sept. 2017 à 18:57, Алексей a écrit : > > Don't you think that line break is a strong punctuation by itself? It could have been. Unfortunately, in JS, it is not. Automatic semi-colon insertion (ASI) could be seen as an attempt to have their cake and eat it too. Or, as a compromise bet

Re: Make comma at the end of line optional

> Le 12 sept. 2017 à 18:00, Алексей a écrit : > > Sorry, but I don't see any problems with example you provide: > > const object = { > get // not a complete declaration statement - so no implicit comma here > y: 2 // continuation of a previous line > > z: x // complete declaration statem

Re: Make comma at the end of line optional

There are [no LineTerminator here] rules in the ES grammar, in order to prevent the most pernicious trap when using ASI: ``` return // implicit semicolon here a = b ``` Those [no LineTerminator here] rules have not been included in constructs that don’t need them. As a result: ``` const object

Re: Native Function Composition

> Le 24 août 2017 à 23:13, Naveen Chawla a écrit : > > That's a syntax for calling functions, not creating a composed function for > being called any time. > > Personally I don't find that proposal compelling because I don't think it > saves much code vs current syntax - it only straightens t

Re: Proposing a conditional assignment (or equals) operator

This feature is more related to null coalescing (evaluate the RHS when the LHS is null) than to optional chaining (evaluate the LHS when the LHS is *not* null). See https://github.com/gisenberg/proposal-nullary-coalescing/issues/1

Re: an operator for ignoring any exceptions

Note that, in a try/catch/finally construct, you can already omit the catch clause if there is a finally clause. The effect, of course, is not to swallow the exception, but, on the contrary, to propagate it as if there was `catch (e) { throw e }`. (The useful part of such a construct is the fina

Re: Migrating to a better communication tool

Previous discussion: https://esdiscuss.org/topic/move-es-discuss-to-discuss-webplatform-org —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Spaceship Operator

> Le 27 juin 2017 à 22:19, Mike Samuel a écrit : > > On Tue, Jun 27, 2017 at 4:13 PM, Isiah Meadows wrote: >> For what it's worth, for most practical purposes, `arr.sort((a, b) => b - >> a))` works well enough. (The only thing it doesn't work well with are NaNs, >> but in practice, those almost

Re: Arrow function followed by divide or syntax error?

> Le 23 mai 2017 à 16:34, Gareth Heyes a écrit : > > Hi all > > I'd like to discuss this:- > > x=x=>{}/alert(1)/+alert(2)// alerts on edge, syntax error on other browsers > > So on Edge it results in two alerts but every other browser it's a syntax > error. Personally I think Edge is right he

Re: {this} object literal

More generally, all keywords are excluded, that makes sense in general as, e.g., `{ if }` could not be equivalent to `{ if: if }`, or `{ yield }` inside a generator function should not be equivalent to `{ yield: yield }`. But yes, one could have special-cases for literals such as `this`, `true`

Re: Strict (non-coercing) expressions

> Le 13 avr. 2017 à 08:39, T.J. Crowder a > écrit : > > In the thread on [strict relational operators][1], felix [suggested][2] an > expression mode affecting all operators: > > > Maybe every operator can have a non-coercing variant? > > > > One possible syntax is to have a modifier on operat

Re: new [[HasProperty]] invariant for non-extensible objects

> Le 6 mars 2017 à 11:10, Raul-Sebastian Mihăilă a > écrit : > > To be more explicit, the invariants allow this surprising behavior: > > ```js > Object.preventExtensions(nonStandardExoticObject); > Object.isExtensible(nonStandardExoticObject); // false > > 'foo' in nonStandardExoticObject; //

Re: Proposal: a more consistent and stricter number converting function - Number.of()

> Le 24 févr. 2017 à 04:50, 段垚 a écrit : > > Hi, > > > Converting an arbitray value to a number in JS can be rather inconsistent and > unexpected: > > * `null` and `undefined` are different: `+null === 0` but `+undefined` is NaN. > > * Empty string and non-nubmeric strings are different: `+

Re: Or Equal Operator

> Le 4 févr. 2017 à 02:12, Артем Гуржий a écrit : > > Hi, I was thinking, is there a proposal for `or equal` operator as in ruby, > or is there any sense for doing so? > Example: > ```js > let a = 1; > let b = 0; > a ||= b; > ``` > Would be interpreted as > ```js > a = a || b; > ``` > PS: > Rub

Re: Short Comparing proposal

> Le 3 févr. 2017 à 21:05, Bob Myers a écrit : > > If you're worried about short-circuiting, then > > ``` > [() => a, () => b].some(x => c === x()) > ``` Even shorter: `(_ => _ === a || _ === b )(c)` But more seriously: Now you have another issue, namely readability. —Claude ___

Re: Determining if an object can be constructed

> Le 24 janv. 2017 à 19:12, Isiah Meadows a écrit : > > To clarify, I'm wanting to know if it's a callable that isn't a class. > Technically, I could use `Function.prototype.toString` for most > practical purposes of mine, but that'd be super slow (I'd need it in a > warm loop), and wouldn't cat

Re: Determining if an object can be constructed

> Le 19 janv. 2017 à 13:46, Andrea Giammarchi a > écrit : > > If you are looking for isClass or similar you can also rely on > `Function.prototype.toString` decompilation, which is de facto consistent. > > ```js > const isClass = (fn) => > typeof fn === 'function' && > !isClass.toString.c

Re: Determining if an object can be constructed

> Le 19 janv. 2017 à 13:18, Isiah Meadows a écrit : > > Inline. > > On Thu, Jan 19, 2017, 03:26 Claude Pache <mailto:claude.pa...@gmail.com>> wrote: >> Le 17 janv. 2017 à 23:48, Isiah Meadows > <mailto:isiahmead...@gmail.com>> a écrit : >> &

Re: Determining if an object can be constructed

> Le 17 janv. 2017 à 23:48, Isiah Meadows a écrit : > > Out of curiosity, why are classes specified to have a [[Call]] internal > method instead of special-casing `typeof` and friends to work with them? > Somewhat of a tangent, but just a curious question on the design decision. > I guess tha

Re: Determining if an object can be constructed

> Le 17 janv. 2017 à 23:56, Oriol _ a écrit : > > See my > http://stackoverflow.com/questions/39334278/check-if-object-is-a-constructor-isconstructor > > > > I also thought the `extends` trick could

Re: Determining if an object can be constructed

> Le 16 janv. 2017 à 18:00, Michael Haufe a écrit : > > The question came up recently on CLJS [1] on how to determine if an object is > safe to call as a Constructor. The two following procedures will determine whether an object is a constructor without running it, according to ES6. (Whether

Re: Destructuring object outside of var declaration

> Le 14 nov. 2016 à 22:53, Boris Zbarsky a écrit : > >> On 11/13/16 1:28 PM, Thaddee Tyl wrote: >>var foo, bar; >>{foo, bar} = {foo: 2, bar: 3}; >> >> is a "SyntaxError: expected expression, got '='" in Firefox, and *it >> works in Google Chrome*. > > I get "Uncaught SyntaxError: Unex

Re: Wrapping regex's with proxies isn't working

> Le 10 nov. 2016 à 15:50, Isiah Meadows a écrit : > > This could be resolved by checking the underlying non-proxy object and using > that one's internal slots instead, in each language-level method that checks > that. > Such semantics could make impossible to write impermeable proxies for s

Re: Wrapping regex's with proxies isn't working

> Le 10 nov. 2016 à 14:59, Angel Scull a écrit : > > Hello, > > I’ve tried this code and seems that there is some weird type checking > somewhere that causes this exception. > > TypeError: Method RegExp.prototype.exec called on incompatible receiver > [object Object] > > > let pattern =

Re: Power operator, why does -2**3 throws?

The existence of traps in the language is not an argument for adding other ones. On the contrary, we must learn from previous problematic design decisions, in order not to repeat the same errors. Also, the language feeling more quirky is less a severe issue than the language inducing to produce

Re: Why Number(symbol) crashes?

> Le 11 oct. 2016 à 11:07, medikoo a écrit : > > I was searching the archived but wasn't able to find the answer. > > What's the reasoning behind having Number(symbol) crash instead of returning > NaN (as it's in case all other non-coercible values?). It feels not > consistent. > > If someone

Re: Power operator, why does -2**3 throws?

> Le 14 oct. 2016 à 16:52, Rick Waldron a écrit : > > Python is also inconsistent: > > >>> pow(-2, 2) > 4 > >>> -2 ** 2 > -4 > >>> This is not inconsistency, but that follows from operator precedence rules (those used in mathematics, not in C). In the same vein, you have `pow(1+1, 2) == 4`

Re: Existential Operator / Null Propagation Operator

> Le 13 oct. 2016 à 19:20, Bob Myers a écrit : > > Why is this needed? Why are people trying to get the property of an object > which is null? Why is the object null in the first place? This is not about trying to get something from null, but about taking different paths according to when a

Re: Existential Operator / Null Propagation Operator

> Le 13 oct. 2016 à 17:32, Isiah Meadows a écrit : > > It may be a good idea to create a pull request for it if it isn't listed yet > I've already tried some time ago: https://github.com/tc39/ecma262/pull/340 —Claude___ es-discuss mailing list es-dis

Re: Existential Operator / Null Propagation Operator

> 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 reason why this proposal > has stalled. If not, what is the problem here? The iss

Re: Existential Operator / Null Propagation Operator

> Le 13 oct. 2016 à 14:37, Kagami Rosylight a écrit : > > > Or `!.`, which unfortunately is now being used by TypeScript? What is exactly the issue you're trying to solve? The token `?.` works fine (technically with a simple lookahead for excluding digit after it). —Claude _

Re: Feature Request: Make ECMA262 a superset of JSON

Besides U+2028 and U+2029, there is also the __proto__ key, which has a special meaning in JS as implemented in browser. That prevents definitely to "safely" embed arbitrary JSON within JS. —Claude > Le 29 sept. 2016 à 23:21, Richard Gibson a écrit : > > ECMAScript claims JSON as a subset twi

Re: Proposal: Array.prototype.first() and Array.prototype.last()

> Le 28 sept. 2016 à 07:38, 段垚 a écrit : > > Because `foo.bar` is equivlant to `foo['bar']` in JS so far, and `array.-1` > could break this consistency. > > > On the other hand, `array.first()` seems not necessary because `array[0]` is > even more handy; `array.last()` looks fine to me. > >

Re: Syntax Proposal: Anonymous Arguments

> Le 23 sept. 2016 à 20:35, Kenneth Powers a écrit : > > As for resolving ambiguity, why not just do what Scala does > ? > It would seem to me that nesting these functions would be a sign

Re: Optional Chaining (aka Existential Operator, Null Propagation)

> Le 25 août 2016 à 17:17, Claude Pache a écrit : > > >> Le 25 août 2016 à 16:05, Alexander Mekhonoshin > <mailto:invn...@yandex-team.ru>> a écrit : >> >> >> 2. unary ?. >> >> window?.navigator?.toString() >> >> browser

Re: Optional Chaining (aka Existential Operator, Null Propagation)

> Le 25 août 2016 à 16:05, Alexander Mekhonoshin a > écrit : > > > > 3. groupped ?.() > Syntax for the full existential chain case: > > .?(a.b.c) // equals with typeof a !== 'undefined' && a.b && a.b.c > In other words, `.?(a.b.c)` (or whatever other syntax) is approximately equivalent to

Re: Optional Chaining (aka Existential Operator, Null Propagation)

> Le 25 août 2016 à 16:05, Alexander Mekhonoshin a > écrit : > > > 2. unary ?. > > window?.navigator?.toString() > > browser: "[object Navigator]" > node: ReferenceError: window is not defined > > here i suggest syntax for exception-slient accesing globals: > > ?.a === hostGlobalObject?.a

Re: Symbol.hasInstance and [[Get]] vs [[GetOwnProperty]]

>> ```js >> Uncaught TypeError: Cannot read property 'call' of undefined >> ``` >> > > (...) > > Also, reading the message of your TypeError, I wonder if Babel may also fail > unexpectedly in case SomeClass does not inherit the standard `Function#call`, > as in: ```class SomeClass { static cal

Re: Symbol.hasInstance and [[Get]] vs [[GetOwnProperty]]

> Le 24 août 2016 à 03:35, /#!/JoePea a écrit : > > > if you want to revert to the default behavior set the value of B or C’s > > [Symbol.hasInstance] own property to undefined. > > That just causes errors. In my environment (Babel), > > ```js > Object.defineProperty(SomeClass, Symbol.hasInst

Re: Symbol.hasInstance and [[Get]] vs [[GetOwnProperty]]

Your mileage may vary, but for me it is, on contrary, intuitive that a subclass inherits by default all the methods of its superclass, without arbitrary exceptions such as `[Symbol.hasInstance]()`. Whether it is desirable, I am sure it depends on what you put in the `[Symbol.hasInstance]()` met

Re: Why ES6 introduced classes yet `Symbol` not to be used with `new`?

> Le 15 août 2016 à 07:33, Kris Siegel a écrit : > > Interesting. > > Because, to be consistent with Number/String/Boolean you would expect `new > Symbol()` to create a Symbol wrapper object. > > Currently Symbol is the only primitive that can't be converted to a string > through the use of

  1   2   3   4   5   >