Re: Proposal: syntactic sugar for extracting fields from objects

I don't know what "community" means, other than a bunch of people subscribing to this ML, and I can't imagine how one would define, or achieve, or identify, a "consensus" of that community, or why or how the community would vote on anything, or what such the results of such a vote would mean. The

Re: Proposal: syntactic sugar for extracting fields from objects

Not a rule. Just an email to this board. On Thu, May 30, 2019 at 7:26 AM Григорий Карелин wrote: > I'm new to this community, so I'd appreciate if you clarify: is that your > opinion or is it kind of rule written somewhere? > > чт, 30 мая 2019 г. в 09:59, guest271314 : > >> > Wouldn't it be

Re: Proposal: syntactic sugar for extracting fields from objects

I'm new to this community, so I'd appreciate if you clarify: is that your opinion or is it kind of rule written somewhere? чт, 30 мая 2019 г. в 09:59, guest271314 : > > Wouldn't it be better to consolidate the decision? I mean as OP I vote > for `from`, but if majority will say they better like

Re: Proposal: syntactic sugar for extracting fields from objects

> Wouldn't it be better to consolidate the decision? I mean as OP I vote for `from`, but if majority will say they better like `x.{y, z}` I'll take it. No. There should not be any prohibition as to the additions different solutions to a single proposal. Neither proposal is "better" right now as

Re: Proposal: syntactic sugar for extracting fields from objects

Wouldn't it be better to consolidate the decision? I mean as OP I vote for `from`, but if majority will say they better like `x.{y, z}` I'll take it. чт, 30 мая 2019 г. в 06:35, guest271314 : > > I think it's possible to find someone who will represent the will of > community. > > Individuals

Re: Proposal: syntactic sugar for extracting fields from objects

> I think it's possible to find someone who will represent the will of community. Individuals can compose the code right now. > At the moment the question is does community have will to add proposed sugar to the language, and if so, which version. Why would there be any restriction on the

Re: Proposal: syntactic sugar for extracting fields from objects

True I think it's possible to find someone who will represent the will of community. At the moment the question is does community have will to add proposed sugar to the language, and if so, which version. ср, 29 мая 2019 г. в 22:30, Oriol _ : > If you want to add this you will need a champion,

Re: Proposal: syntactic sugar for extracting fields from objects

If you want to add this you will need a champion, see https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#new-feature-proposals -- Oriol El 29/5/19 a les 21:15, Григорий Карелин ha escrit: I agree. So, what does community think? Do we want to have “destructuring picking” sugar in JS

Re: Proposal: syntactic sugar for extracting fields from objects

I agree. So, what does community think? Do we want to have “destructuring picking” sugar in JS and if we do, which syntax looks more attractive? I’d suggest to vote. On Wed, 29 May 2019 at 21:55, Bob Myers wrote: > This syntax merely combines and extends two existing notations: > > 1. Dot

Re: Proposal: syntactic sugar for extracting fields from objects

This syntax merely combines and extends two existing notations: 1. Dot notation to access properties, which has been in JS since it was initially designed, with the RHS extended to permit a *set* of properties in `{}` in addition to a plain old identifier as at present. 2. Property spread

Re: Proposal: syntactic sugar for extracting fields from objects

Well, I guess it might work too. I personally like more verbose constructions, with keywords instead of dots, asterisks, etc :) On Wed, 29 May 2019 at 21:03, Bob Myers wrote: > On Wed, May 29, 2019 at 10:28 AM Григорий Карелин > wrote: > >> Hi Cyril, >> With the syntax you propose what would

Re: Proposal: syntactic sugar for extracting fields from objects

On Wed, May 29, 2019 at 10:28 AM Григорий Карелин wrote: > Hi Cyril, > With the syntax you propose what would be the way to to this: > ``` > const source = {foo: 1, bar: 2}; > const result = {foo: source.foo, bar: source.bar, buzz: 3} > ``` > ? > As already mentioned earlier in this thread:

Re: Proposal: syntactic sugar for extracting fields from objects

Hi Cyril, With the syntax you propose what would be the way to to this: ``` const source = {foo: 1, bar: 2}; const result = {foo: source.foo, bar: source.bar, buzz: 3} ``` ? ср, 29 мая 2019 г. в 20:14, Cyril Auburtin : > What I'd like is this syntax: > > ```js > let o={a:1, b:2, c:3}; > o.{a, b}

Re: Proposal: syntactic sugar for extracting fields from objects

What I'd like is this syntax: ```js let o={a:1, b:2, c:3}; o.{a, b} // would be {a: 1, b: 2} ``` On Tue, May 28, 2019 at 9:13 PM Григорий Карелин wrote: > Here are another examples, where "destructuring picking" I suggest whould > be helpful. > ==1A Now (redux related) > ``` > function

Re: Proposal: syntactic sugar for extracting fields from objects

Here are another examples, where "destructuring picking" I suggest whould be helpful. ==1A Now (redux related) ``` function mapStateToProps({user: {firstName, lastName}, common: {currentPageURL: url}}) { return {firstName, lastName, url}; } ``` ==1B Proposal ``` function mapStateToProps(state) {

Re: Proposal: syntactic sugar for extracting fields from objects

> > ``` >> let obj = {otherData: "other data"}; >> ({firstName:obj.firstName, lastName:obj.lastName} = user.profile); >> ``` > > I don't understand this. > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assigning_to_new_variable_names He's

Re: Proposal: syntactic sugar for extracting fields from objects

> > ``` > let obj = {otherData: "other data"}; > ({firstName:obj.firstName, lastName:obj.lastName} = user.profile); > ``` > I don't understand this. > Alternatively there are various approaches which can be used to get only > specific properties from an abject and set those properties and

Proposal: `Array.prototype.chunks` and `Array.prototype.windows`

Apologies if this has already been suggested and discussed somewhere, but I couldn't find anything. I'm learning Rust at the moment, and found myself wishing that JavaScript had `chunks` and `windows` array methods. https://doc.rust-lang.org/std/primitive.slice.html#method.windows

Re: Proposal: syntactic sugar for extracting fields from objects

> Is the expected result for ```obj``` to be defined as a variable and ```firstName``` and ```lastName``` to not be defined as variables? Exactly As you mentioned above, we may use default value while destructuring to achieve the same result, but it looks quite unobvious and creates extra

Re: Proposal: syntactic sugar for extracting fields from objects

In this case you can utilize a single step by setting a default value for ```otherData``` ```let {firstName, lastName, otherData = "otherData"} = user.profile;``` On Sun, May 26, 2019 at 2:56 PM Григорий Карелин wrote: > Yep, in the same way as destructuring would work > > вс, 26 мая 2019 г.

Proposal: syntactic sugar for extracting fields from objects

Similar proposals have been out there for years. For whatever reason, none have gotten traction. Under one proposal, your scenario would be ``` const obj ={...user_profile.{firstName, lastName}, otherData: 'other data'}; ``` https://github.com/rtm/js-pick-notation Bob -- Forwarded

Re: Proposal: syntactic sugar for extracting fields from objects

I tried to see if I could do this in a single destructuring step, but here is what happened: ``` var user = { profile: { firstName: 'Bob', lastName: 'Ruffward', x: 'hi' } } var obj = { ...({firstName, lastName} = user.profile), otherData: 'otherData' } ``` So... what happened? (I'm sure you all

Re: Proposal: syntactic sugar for extracting fields from objects

Yep, in the same way as destructuring would work вс, 26 мая 2019 г. в 17:52, guest271314 : > If not found in source ```firstName``` and/or ```lastName``` would be > assigned the value ```undefined```? > > On Sun, May 26, 2019 at 1:40 PM Григорий Карелин > wrote: > >> Wouldn't it be nice to have

Re: Proposal: syntactic sugar for extracting fields from objects

If not found in source ```firstName``` and/or ```lastName``` would be assigned the value ```undefined```? On Sun, May 26, 2019 at 1:40 PM Григорий Карелин wrote: > Wouldn't it be nice to have syntax like this: > const obj = { {firstName, lastName from user.profile}, otherData: 'other > data'

Proposal: syntactic sugar for extracting fields from objects

Wouldn't it be nice to have syntax like this: const obj = { {firstName, lastName from user.profile}, otherData: 'other data' }; as a syntactic sugar for const obj = {firstName: user.profile.firstName, lastName: user.profile.lastName, otherData: 'other data'}; Of cause at the moment we can write

Re: how many async-modules can js-app practically load?

> If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. What specifically should be compared? What are you trying to determine? The current question asks > how many async-modules can js-app practically load?

Re: how many async-modules can js-app practically load?

If you come up with a benchmark for this, would you mind sharing the code and not just the results? I'm curious how my stuff will fare. I'm in an environment where it is still not practical to use ES modules, and have started work again on BravoJS, which implements the old CommonJS Modules/2.0

Re: how many async-modules can js-app practically load?

Have not tried babel or webpack. You can write the test to answer your own inquiry and post the result at a gist. On Sat, May 25, 2019 at 6:34 AM kai zhu wrote: > Why would 50 separate

Re: how many async-modules can js-app practically load?

> Why would 50 separate

Re: how many async-modules can js-app practically load?

> so async-loading 50

Re: how many async-modules can js-app practically load?

> Asynchronous loading differs only in > that it takes more code to express the same logic and you have to take > into account concurrent requests (and you need to cache the request, > not the result), but it's otherwise the same from 1km away. so async-loading 50

Re: how many async-modules can js-app practically load?

There's two main reasons why it scales: 1. Modules are strongly encapsulated while minimizing global pollution. 2. The resolution algorithm applies the same logic no matter how many modules are loaded. It's much easier for it to scale when you write the code unaware of how many modules you might

Re: Re: Indexing HTML Attributes and Unique Indexes

You'd have better luck asking for this feature in https://discourse.wicg.io. ES Discuss is about the JS language itself and the related ECMAScript spec, not the Web APIs that are implemented in most browsers, usually separately to the JS implementations themselves. - Isiah Meadows

Re: Re: Indexing HTML Attributes and Unique Indexes

> I want to avoid dealing with HTML Using HTML is part of premise of the proposal, correct? Am still not sure what the actual requirement is. If the requirement is to prevent duplicate _values_ being input by the user you can utilize ```pattern``` attribute of `` with a ```RegExp``` which

Re: Re: Indexing HTML Attributes and Unique Indexes

Sorry. My confusion. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Indexing HTML Attributes and Unique Indexes

> while it could be considered a sub-set, JS is full of HTML related features - `HTMLElement` for one. HTMLElement is defined by the living DOM standard (WHATWG) https://html.spec.whatwg.org/multipage/dom.html#htmlelement it has nothing to do with JS. JS is a general purpose programming

Re: Re: Indexing HTML Attributes and Unique Indexes

@Andrea Giammarchi, While the connection is secondary, HTML often serves as the specification for the creation of JS objects. And while it could be considered a sub-set, JS is full of HTML related features - `HTMLElement` for one. Thing is, if you are

Re: how many async-modules can js-app practically load?

actually, i admit i don't know what i'm talking about. just generally confused (through ignorance) on how large-scale es-module dependencies resolve when loaded/imported asynchronously. On Wed, May 22, 2019 at 10:42 PM Logan Smyth wrote: > Can you elaborate on what loading state you need to

Re: Re: Indexing HTML Attributes and Unique Indexes

it's meant there couldn't be two indexes with the same value, but even IDs can be duplicated on a page (it's not suggested or anything, but nothing prevents you to do that) to be honest, since IDs already cover the whole story (IDs are accessible even via globalThis/window, no need to query the

Re: Re: Indexing HTML Attributes and Unique Indexes

If the HTML elements have a unique ```id``` set there is not search to perform (```document.getElementById("id")```), correct? Form fields can be created, set and changed using `FormData` objects without using HTML elements at all. Still not gathering what is meant by unique indexes. On Thu,

Re: Re: Indexing HTML Attributes and Unique Indexes

Full Table Scans and Unique indexes are database concepts (that's the DBA reference). When a database searches for a record based on a column value, it might look at every record in the table to find the matches - scan the entire (full) table, in the order the records were inserted or stored.

[no subject]

I saved 136 MB on my phone using Files by Google! Can you save more? Try it at g.co/filesgo #filesbygoogle ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: how many async-modules can js-app practically load?

Can you elaborate on what loading state you need to keep track of? What is the bottleneck that you run into? Also to be sure, when you say async-load, do you mean `import()`? On Wed, May 22, 2019, 20:17 kai zhu wrote: > i don't use es-modules. > but with amd/requirejs, I start having trouble

how many async-modules can js-app practically load?

i don't use es-modules. but with amd/requirejs, I start having trouble with module-initializations in nodejs/browser at ~5 async modules (that may or may not have circular-references). 10 would be hard, and 20 would be near inhuman for me. can we say its somewhat impractical for most

Re: Indexing HTML Attributes and Unique Indexes

> Thanks for the link. My current approach is similar to what you and the article describe. Maybe it’s just the old DBA in me, but even when I narrow my parameters `(node.querySelector(“[…]”))` it feels like I’m doing a lot of “full table scans” when I would want to index some of the “columns”.

Re: Indexing HTML Attributes and Unique Indexes

> About being unique, you can always > `document.querySelector('[attribute="' + value +'"]')` This code is vulnerable to CSS injection, input values shouldn't be inserted raw into queries! You can use `CSS.escape` to sanitize. -- Oriol ___

Indexing HTML Attributes and Unique Indexes (Randy Buchholz)

Sounds like a job for decorators. `lit-element` provides something very close to at least part of what you seem to want (the getters and setters that is, not the indexing or "distinct" functionality). Bob -- Forwarded message -- > From: Randy Buchholz > To:

RE: Indexing HTML Attributes and Unique Indexes

Thanks for the link. My current approach is similar to what you and the article describe. Maybe it’s just the old DBA in me, but even when I narrow my parameters `(node.querySelector(“[…]”))` it feels like I’m doing a lot of “full table scans” when I would want to index some of the “columns”.

Re: Indexing HTML Attributes and Unique Indexes

live * On Wed, May 22, 2019 at 7:25 PM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > With Custom Elements you have `attributeChangedCallback` which reacts > after `observedAttributes` returned attributes, and I believe you'd like to > use that to create getters and setters out of the

Re: Indexing HTML Attributes and Unique Indexes

With Custom Elements you have `attributeChangedCallback` which reacts after `observedAttributes` returned attributes, and I believe you'd like to use that to create getters and setters out of the box. I don't think DOM specific class fields/syntax will ever land in JS itself, but I can suggest

Indexing HTML Attributes and Unique Indexes

I've been working with `Custom Elements` and I'm writing a lot of code against tag attributes. In some cases, I want the attribute values to be unique on a page (like `id`). It got me wondering about how the engines handle attribute based searches, and if indexing (with unique/distinct

Re: Re: Proposal: native XML object support.

As a data point -- I was writing JavaScript applications with GPSEE, a server-side Spidermonkey embedding, for several years until recently. The design pattern was, for all intents and purposes, CGI. GPSEE has E4X capability. I used it a few times to generate xhtml documents. I never found a

Re: Re: Proposal: native XML object support.

JSX doesn't necessarily need a vDOM. On Tue, May 21, 2019, 10:31 kai zhu wrote: > jsx is not terribly javascripty ... vs direct manipulation of the dom > (using static-functions/handlers). > > it requires two extra ux-workflow transformations -- 1) transpilation and > 2) virtual-dom

Re: Re: Proposal: native XML object support.

jsx is not terribly javascripty ... vs direct manipulation of the dom (using static-functions/handlers). it requires two extra ux-workflow transformations -- 1) transpilation and 2) virtual-dom manipulation, for the sake of oft-quoted faster dom-performance, which some like me are skeptical is

Re: Re: Proposal: native XML object support.

People use JSX, which is basically E4X, so I'd argue the word useless is not really appropriate. You can use E4X to produce HTML, the fact we're talking XML is merely about the E4X background, but as you could produce strings out of E4X you could do the same and have better templating out of the

Re: Proposal: native XML object support.

fyi, a notable xml-based web-api holdout is wechat-pay, with a billion active users [1],[2]. arch-rival alipay otoh uses json. -kai [1] official wechat-pay documentation https://pay.weixin.qq.com/wiki/doc/api/download/wxpay_document.zip [2] swagger documentation for wechat-pay

Re: Proposal: native XML object support.

I'm not sure why is that discussed. XML is natively supported in browsers and there are npm packages to bring exactly the same interface to Node.js and other server envs. If you want Node.js to include some kind of XML parser in its core library, I suggest using their bug tracker (but it was

Re: Proposal: native XML object support.

My bad. I should've known that. :-) (I've looked *way* too deeply into the React/Redux ecosystem to have any sort of excuse on this one.) - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Wed, May 15, 2019 at 11:39 PM Jordan Harband wrote: > > (that's not react's creator;

Re: Re: Proposal: native XML object support.

> the client, it could still somehow shine in NodeJS though. The only way it can shine is only passing HTML objects as arg to website. That’s it. And still, you can use string to do that for you. People already use JSON and I don’t think they would use XML in Node js. There are already tons of

Re: Re: Proposal: native XML object support.

That'd give you info after declaration, which I believe was the major concern in using strings instead of literals. FWIW, I also wish E4X was still a thing, despite these handy and successful template literals based libraries (hyperHTML, lighterhtml, or heresy for the client, viperHTML for

Re: Re: Proposal: native XML object support.

> With strings and even E4X, you don't get the same experience that react > supports. Things like property completion in XML mode, XML internal logic, > etc. Pretty sure you can do this: ```js // ... xml function definition /** * @type {Element} * @prop {string} href */ const xmlObj =

javascripty-ness or python-like idioms for javascript

coming from a python background, it would be nice if javascript had some core design-philosophy to guide its evolution rather than haphazardly following fads and cues from other languages. currently, my strawman idea of what constitutes javascripty-ness is: "achieving your ux-workflow objective,

Re: Re: Proposal: native XML object support.

With strings and even E4X, you don't get the same experience that react supports. Things like property completion in XML mode, XML internal logic, etc. From: es-discuss on behalf of liorean Sent: Monday, May 20, 2019 3:03:04 AM To: Jacob Bloom Cc:

Re: Re: Proposal: native XML object support.

You could already do something like this: let RawXML=xml`some content` ,XMLApplication=rss` RSS Title This is an example of an RSS feed http://www.example.com/main.html Mon, 06 Sep 2010 00:01:00 + Sun, 06 Sep 2009 16:20:00 +

Re: Re: Proposal: native XML object support.

> And things such as E4X already exist. Building on that, JSX is just a code transformation that can be used without React. You can swap React out for another compatible library with a pragma: https://babeljs.io/docs/en/next/babel-plugin-transform-react-jsx#pragma -- JSX + a React-like library

Re: Re: Proposal: native XML object support.

XML in JS without React could totally bring usage in Node js, not only JS. For example, you could pass XML object as parameter to website from server and server would change it to right way, so XML object would be turned to HTML element. However, in non web-development environment, it would

Re: Proposal: native XML object support.

(that's not react's creator; that's redux's creator, who is now a member of the react core team) On Wed, May 15, 2019 at 8:17 PM Isiah Meadows wrote: > Fun fact: React elements are plain JS objects that are nearly > JSON-compatible. The only reason why they aren't is because of the presence >

Re: Proposal: Add new 'Matrix' object

Check out the old (and retracted) SIMD.js proposal that aimed to bring SIMD support to JS and the related offshoot that attempted to cover WebAssembly interop as well. https://github.com/tc39/ecmascript_simd https://github.com/stoklund/portable-simd/blob/master/README.md Also, WebAssembly has a

Re: Proposal: native XML object support.

Fun fact: React elements are plain JS objects that are nearly JSON-compatible. The only reason why they aren't is because of the presence of a `$$typeof: Symbol.for("react.element")` property on React elements, to prevent people from using non-array object results of `JSON.parse(jsonString)`

Re: Proposal: Add new 'Matrix' object

this is wishful thinking, but i've wondered whether [wasm] sqlite3 has better potential for general-purpose multidimensional vector-operations than whatever gets spec'ed out in javascript. probably not, but there's been research on sql "dot-product-joins" [1]. [1] Dot-Product Join: Scalable

Re: Proposal: native XML object support.

> I prefer JSON over XML any time but the only area where JSON can't compete with XML is UI. XML is also currently specified as the language used by SSML. Why does a JavaScript plain object need to be created when the XML document itself can be used to read/write values? ``` const

Re: Proposal: Add new 'Matrix' object

A matrix could be viewed as an array of arrays or sets or maps or other values. How the values in the arrays or indexes are mapped is dependent upon the requirement. The requirement could be to map the networks of this entire planet earth; create sets of permutations; create cross word puzzles.

Re: Proposal: native XML object support.

I prefer JSON over XML any time but the only area where JSON can't compete with XML is UI. From: es-discuss on behalf of Sanford Whiteman Sent: Tuesday, May 14, 2019 1:56:46 AM To: es-discuss@mozilla.org Subject: Re: Proposal: native XML object support. > I

Re: Proposal: native XML object support.

> I don't think we can say that we live in a JSON centric world But we do. It's not that there aren't powerful XML-based applications still being developed. And XML still buttresses some of the most important back-end components of the modern (as well as ancient) web. But surely you cannot have

Re: Proposal: native XML object support.

Thanks for reply. Didn't know that it existed before! I don't think we can say that we live in a JSON centric world when things like React show up and revolutionize web development. I think JSON has its uses and XML has its uses. UI shouldn't been ever seperated from controller since one can't

Re: Proposal: native XML object support.

> let foo = This is a retread of E4X (https://en.wikipedia.org/wiki/ECMAScript_for_XML) so I can't imagine it would be resuscitated in a (for better or worse) JSON-centric world. —— Sandy ___ es-discuss mailing list es-discuss@mozilla.org

Proposal: native XML object support.

Hello, I am proposing to support XML object native in JavaScript so the following code would be possible let foo = Which creates an object called foo with name = "input" and value = "Ok", children = null, and constructor = null `constructor` property would include a constructor to be

Re: Proposal: Add new 'Matrix' object

is that a tentative "no" as in tc39 can't easily spec some low-level linear-algebra primitives that would be useful for both dommatrix, and [gpu-accelerated] tensoflow? i do find value to industry for enhancing client-side performance of 3d visualization and ML. and i'm starting to see @Ed's

Re: Proposal: Add new 'Matrix' object

According to the specs, DOMMatrix is limited to 4d matrices. They can be used to emulate 1d-3d matrices trivially. However, many applications (e.g. in graph theory) require arbitrary numbers of dimensions. I'm not really familiar with Tensorflow, but if I read the API correctly, it seems to be

Re: Proposal: Lazy Error.message

Also, there's nothing preventing subclasses of Error to return a function as message (or any other complex object). In chrome you can also reassign a function to a existing error message, I didn't tested others browsers. User interfaces/libraries can check if a message is a function or not (giving

Re: Proposal: Add new 'Matrix' object

Neither ```DOMMatrix``` nor tensorflow functionality are exclusive to any single use case. What is the use case of the Matrix object described at this proposal? On Sun, May 12, 2019 at 7:06 PM kai zhu wrote: > from what i can tell 1) w3c dommatrix is application-specific to 3d > visualization

Re: Proposal: Add new 'Matrix' object

from what i can tell 1) w3c dommatrix is application-specific to 3d visualization and 2) tfjs is application-specific to gpu-accelerated machine-learning. the question is, is it feasible to spec a tc39 "jack-of-all-trades" linear-algebra proposal that can underpin the above two (and many other)

Re: Proposal: Math.add, Math.sub

Terse ```add``` code ```const add = a => eval(a.join`+`)`. Would fix JavaScript floating point number precision issues and implement ```BigDecimal``` first. On Sat, May 11, 2019 at 11:21 PM Ates Goral wrote: > (Percolating a comment I made in a thread earlier.) > > # Math.add > > ``` >

Re: Proposal: Add new 'Matrix' object

Is this proposal different from ```DOMMatrix()``` https://developer.mozilla.org/en-US/docs/Web/API/DOMMatrix ? On Sun, May 12, 2019 at 9:51 AM Ed Saleh wrote: > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and > AI. I am proposing a new object type of `Matrix([

Re: Proposal: Add new 'Matrix' object

On Sun, May 12, 2019 at 2:51 AM Ed Saleh wrote: > Hello, > > Matrices are widely used today in in Computer Science, Engineering, and > AI. I am proposing a new object type of `Matrix([ []... ])` which would > make working with matrices easier, easily doing operations such matrices >

Re: Proposal: Add new 'Matrix' object

@ed, general-purpose matrix-ops work poorly with malformed data like ```[1.2, null, 4.234]``` which are ubiquitous in ux-workflow programming. my experience in javascript linear-algebra mostly devolves to writing divide-by-zero "technical-debt" that's non-reusable/application-specific. it

Proposal: Add new 'Matrix' object

Hello, Matrices are widely used today in in Computer Science, Engineering, and AI. I am proposing a new object type of `Matrix([ []... ])` which would make working with matrices easier, easily doing operations such matrices `multiplication` and `addition`. Thank you,

Re: Re: New Proposal: Number.range (Yes, range again)

Fully Support ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: Math.add, Math.sub

>const sum = array.reduce(Math.add); It is better not to do this... because the Array#reduce passed 4 parameters to callback. >array.sort((a, b) => a - b); This comparator will not give you a good result when the platform does not support denormalized numbers, as the difference

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

This example could be fixed by passing `{}` as the proxy target. On Fri, May 10, 2019 at 01:23 Claude Pache wrote: > > > 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

Re: Proposal: Math.add, Math.sub

On Sat, May 11, 2019 at 7:38 PM Ates Goral wrote: > > (Percolating a comment I made in a thread earlier.) > > # Math.add > > ``` > Math.add = function (a, b) { > return a + b; > }; What should Math.add('1', '2') produce? - Sam Ruby ___ es-discuss

Proposal: Math.add, Math.sub

(Percolating a comment I made in a thread earlier.) # Math.add ``` Math.add = function (a, b) { return a + b; }; ``` A why: With functional-style programming becoming more and more common with the advent of ES5 Array methods, the terse way to find the sum of items in an array can become even

Hacking onerror/throw

Hi all I’ve been having fun with onerror and throw to call functions passing the argument without using parentheses or template strings. It’s useful for XSS in certain situations where you have a restricted amount of characters. For example you can do the following: ```

Re: Re: Null-coalescing default values in destructuring

Slightly less code (still un-golfed as that does not appear to be the stated requirement described at OP) using the same/similar pattern. let input_json_string = `{"z":null}`; const convertJSONNullToUndefined = json => { const o = JSON.parse(json); for (const key in o) if (o[key] === null)

Re: Proposal: Lazy Error.message

It can already be a getter if you like, which would allow a function to compute the value on demand. On Sat, May 11, 2019 at 6:55 AM _ zaoqi wrote: > Allow Error.prototype.message to be a Function > > It is useful in this case: > > https://github.com/browserify/commonjs-assert/pull/47 > >

Proposal: Lazy Error.message

Allow Error.prototype.message to be a Function It is useful in this case: https://github.com/browserify/commonjs-assert/pull/47 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

Still not gathering the significance or purpose of using ```in``` to generate a boolean output. What appears to be the requirement can be achieved by using ```Set``` or ```Map``` ``` let m = new Map([[0, "a"],[ 1, 1], [2, {}]); m.has(0); // true m.get(2) // {} ``` On Fri, May 10, 2019 at 1:41 PM

Re: Re: Null-coalescing default values in destructuring

The bytes used for code can be reduced. Used redundancy in the original code to handle both cases at the actual examples at OP. ```JSON.stringify()``` and ```replace()``` could be used. The original proposal mentions ```JSON```, though includes the case of ``` const { y =? 'a' } = { y: undefined

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

There are obvious limitations given the masking/ overwriting of the default implementation, but are these limitations not also true for other symbols like `Symbol.hasInstance`? If overwritten (including in a prototype chain), it then masks the original behavior of the `instanceof` operator.

Re: Re: Null-coalescing default values in destructuring

> Given input valid JSON JSON.parse() or JSON.stringify() replacer function can > be utilized to substitute "undefined" for null. guest271314, that’s a lot of code! It feels like if anything, your example backs up the proposal. > `const { z =? 'a' } = { z: null };` I’m not sure I like the

<    5   6   7   8   9   10   11   12   13   14   >