Destructuring equivalent to nullish coalescing and optional chaining operators?

Hello! Has any equivalent feature for the nullish coalescing ?? and optional chaining ?. operators been proposed to paper over the deficiencies of the destructuring syntax with regards to null values? If not, I think one should be proposed. For the entire right side of the binding, an equivalent

Re: Consistency in common operators across various types.

s with an operator such as > <.<=,>,>= of the operators above definition changes depending on the left > and right backing types. > > If both are strings then it does string comparison if both numbers then > its numbers. > Seem great but there are small gotchas. > > So if someone writes

Consistency in common operators across various types.

Hi, Just like to maybe challenge javascript here or any script language in that mater. The definition of comparing two variables with an operator such as <.<=,>,>= of the operators above definition changes depending on the left and right backing types. If both are strings then it

Re: Re: Suggestion: Infix operators/functions

As stated in here, the TypeScript team is highly unlikely to deviate from ECMAScript’s team decisions, so I guess no infix functions in TS for now... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Infix operators/functions

Time to put infix operators into TypeScript, first, then? On Sat, 3 Feb 2018 at 04:25, kdex <k...@kdex.de> wrote: > People in the C++ community have been using overloaded operators since the > 1980's, and I wouldn't say that different semantics for the same operator > have &g

Re: Suggestion: Infix operators/functions

People in the C++ community have been using overloaded operators since the 1980's, and I wouldn't say that different semantics for the same operator have been a bad idea at all, given that the operator handles completely different types (that can and should be statically analyzable). I

Re: Suggestion: Infix operators/functions

I don't like the idea of custom operators only because of readability of code - it can be different for different pieces of code, and so I think it is a larger surface area for bugs, so I think it would be a net negative. However, I do like the idea of allowing e.g. `+` to be used intuitively

Re: Suggestion: Infix operators/functions

s/2319#issue-60851953 > > Since it's very unlikely that the extension methods will ever be > implemented [in a call-site-rewrite > manner](https://github.com/Microsoft/TypeScript/issues/9#iss > uecomment-74302592), > please consider adding infix operators to enable writing in functi

Re: Suggestion: Infix operators/functions

On Fri, Feb 2, 2018 at 10:58 AM, Mike Samuel wrote: > How would this affect ASI? > > a // no semicolon inserted since '+' is an infix operator > +b > > a // semicolon inserted since '!' is not an infix operator > !b > > but what about > > function

Re: Suggestion: Infix operators/functions

extension methods will ever be > implemented [in a call-site-rewrite > manner](https://github.com/Microsoft/TypeScript/issues/9#iss > uecomment-74302592), > please consider adding infix operators to enable writing in functional > style similarly to what can be done in Haskell: >

Re: Suggestion: Infix operators/functions

As it stands, I'd rather see operator overloading before custom operators. In order to have decent custom operators, you really have to take into account the whole grammar, and adding them in a way that's not a blatant tack on usually involves rethinking the entire grammar. In contrast, operator

Re: Suggestion: Infix operators/functions

In ECMAScript's current state, infix operators would likely complicate future discussions of operator overloading. Before we tackle these problems, I think it's more convenient to have type annotations first. On Friday, February 2, 2018 12:55:17 PM CET Thomas Grainger wrote: > I'm port

Suggestion: Infix operators/functions

# issuecomment-74302592), please consider adding infix operators to enable writing in functional style similarly to what can be done in Haskell: Monoids ```js function '+' (left, right) { return left.concat(right); } [1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5] ``` Monads ```js

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

alescing Operator” for the first of your >> suggestions and “Optional Chaining” for the second one. >> >> —Claude >> >> >> >> Le 20 déc. 2017 à 09:03, Arash Motamedi <arash.motam...@gmail.com> a >> écrit : >> >> I’d like to propose t

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

> > 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 Motamedi <arash.motam...@gmail.com> a > écrit : > > I’d like to p

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

03, Arash Motamedi <arash.motam...@gmail.com> a écrit : > > I’d like to propose two new operators that I’ve appreciated using in C#, with > appropriate modifications for Ecmascript. > > ?? Null-Coalescing Operator > > The ?? operator is called the null-coalescing operator.

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

I’d like to propose two new operators that I’ve appreciated using in C#, with appropriate modifications for Ecmascript. ?? Null-Coalescing Operator The ?? operator is called the null-coalescing operator. It returns the > left-hand operand if the operand is not null or undefined; otherw

Re: Strict greater than, greater than or equal, less than and less than or equal comparison operators

See https://esdiscuss.org/topic/strict-relational-operators --Oriol ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Strict greater than, greater than or equal, less than and less than or equal comparison operators

To be able to fully compare number operands with type checking, wouldn't it be nice to have: Strict greater than ( >== ) Strict greater than or equal ( >=== ) Strict less than ( <== ) and Stricht less than or equal ( <=== ) comparison operators which also check for type? We'd

RE: Re: Functional Operators

One question I have: why all these fuzzy (sorry, functional) operators? That could become very hard to know what the code exactly does, and difficult to debug... Are you becoming too "lazy" to type on the keyboard? From: Ron Buckton [mailto:ron.buck...@microsoft.com] Sent: Sunda

RE: Re: Functional Operators

(apologies for top posting as I’m replying from my phone) Functional operators are not very interesting on their own, but are much more interesting in terms of pipelines and partial application. However, they may be a stretch in either scenario, so I’m not expecting them to be part of any

Re: Re: Functional Operators

`+` is not specific to numeric values...) On Sun, Jul 16, 2017 at 2:19 AM, Ron Buckton <ron.buck...@microsoft.com> wrote: > I have been looking into functional operators while working on a proposal > for pipeline and partial application. I’ve found that a sigil like `{+}` is > just as ergonomic as

RE: Re: Functional Operators

I have been looking into functional operators while working on a proposal for pipeline and partial application. I’ve found that a sigil like `{+}` is just as ergonomic as `(+)`, but has fewer lookahead issues with respect to regular expression parsing. While `(/)` is ambiguous as to whether

Re: Functional Operators

+1 on the idea, -1 on the execution. Here's a few things to be aware of: - A single unary or binary operator without parentheses is unambiguous where only expressions are allowed. - If the operators directly desugar to lambdas, you'll have functions that look `===`, but aren't. - The operator

Re: Functional Operators

) => a + b; > ``` > > This definitely helps clear up verbosity in reduce statements and related > functions. Another example would be for sorting: > > ```js > [1,4,3,6].sort((-)); > ``` > > While all operators (namely `=`) wouldn't work as functiona

Re: Re: Functional Operators

`Math.add` etc might represent a more consistent approach to the issue of operators not being function references?) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Functional Operators

) => a + b; ``` This definitely helps clear up verbosity in reduce statements and related functions. Another example would be for sorting: ```js [1,4,3,6].sort((-)); ``` While all operators (namely `=`) wouldn't work as functional operators, I think this would be a useful addition to the langu

Overloading an operators

ECMAScript is and (at least in a near future) will be the only major language for handling application logic in the client, it is essential that ECMAScript has to grow into more complex and capable language as we need it to handle more complex tasks. One concrete way is adding an operators overloading

Re: FW: Re: Strict Relational Operators

Also there was once the is/isnt operators and they lasted in ES6 for a very long time and went pulled for reasons like this. On Apr 15, 2017 4:06 AM, "Isiah Meadows" <isiahmead...@gmail.com> wrote: > Okay, I stand corrected... (I forgot about those) > > On Sat, Apr 15, 2

Re: FW: Re: Strict Relational Operators

eq`. >> >> > Up to date, the only keyword >> > operators have been exclusively unary, such as `typeof`, `await`, >> > and `yield`. >> >> Not quite. :-) As I mentioned when suggesting them originally, there is >> *one* binary non-symbolic operat

Re: FW: Re: Strict Relational Operators

There's also `instanceof`. On Fri, Apr 14, 2017 at 11:31 PM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > Happy with `neq`. > > > Up to date, the only keyword > > operators have been exclusively unary, such as `typeof`, `await`, > > and `yield`. > >

Re: FW: Re: Strict Relational Operators

Happy with `neq`. > Up to date, the only keyword > operators have been exclusively unary, such as `typeof`, `await`, > and `yield`. Not quite. :-) As I mentioned when suggesting them originally, there is *one* binary non-symbolic operator already: `in` ```js if ("foo&qu

Re: FW: Re: Strict Relational Operators

for a common operation. 2. JS is a weakly typed language, and coerces nearly everything. It normally calls `.valueOf()` (if it exists) and coerces the result to numbers for the comparison operators. Strong type checking has generally only been reserved for scenarios that can't be optimized well

FW: Re: Strict Relational Operators

I prefer the idea of keyword operators, like : a lt 1 // strict < 1 a lte 1 // strict <=1 a gt 1 // strict > 1 a gte 1 // strict >= 1 ... That’s easier to understand and memorize. From: Dawid Szlachta [mailto:dawidmj.szlac...@gmail.com] Sent: Friday, April 14,

Re: Re: Strict Relational Operators

elf): > > `a =@=@= b` would be equivalent to `(a === null || b === null) ? (a === > null && b === null) : typeof a === typeof b` - then you could use the > operator to explicitly guard any comparison operators where you wanted the > type to be the same, and throw, return false, or coerc

Re: Re: Strict Relational Operators

b === null) ? (a === null && b === null) : typeof a === typeof b` - then you could use the operator to explicitly guard any comparison operators where you wanted the type to be the same, and throw, return false, or coerce to your heart's content. On Thu, Apr 13, 2017 at 5:35 AM, James Treworgy &

Re: Re: Strict Relational Operators

That would seem to make more sense. At the end of the day, for me, I just don't much value in adding new syntax for operators to do this. The only time I can think of in my own code where this would be useful (in the sense that it would have avoided some extra type check to ensure things work as I

Re: Re: Strict Relational Operators

Yeah. I suggested that if we aren't doing symbolic operators but rather functions or something else, they should result in `undefined` for mixed types, so you can differentiate if appropriate. (Symbolic operators like `<=<` would need to be consistent with `===` and `!==`, though, which

Re: Re: Strict Relational Operators

;tj.crow...@farsightsoftware.com> > wrote: > >> James, are you commenting on felix's idea of strict expressions (in which >> case, I suggest the other thread: https://esdiscuss.org/topic/st >> rict-non-coercing-expressions), or strict relational operators? >> >&g

Re: Re: Strict Relational Operators

strict expressions (in which > case, I suggest the other thread: https://esdiscuss.org/topic/ > strict-non-coercing-expressions), or strict relational operators? > > Other than felix's strict expressions, I don't think anyone was suggesting > that strict relational operators s

Re: Re: Strict Relational Operators

James, are you commenting on felix's idea of strict expressions (in which case, I suggest the other thread: https://esdiscuss.org/topic/strict-non-coercing-expressions), or strict relational operators? Other than felix's strict expressions, I don't think anyone was suggesting that strict

Re: Re: Strict Relational Operators

type guard clauses to function arguments that are evaluated at runtime. On Apr 13, 2017 2:44 AM, "T.J. Crowder" <tj.crow...@farsightsoftware.com> wrote: > I've started a separate thread to discuss felix's idea of an expression > mode making all operators within it non-coe

Re: Re: Strict Relational Operators

I've started a separate thread to discuss felix's idea of an expression mode making all operators within it non-coercing (as it's rather more broad than this topic): https://esdiscuss.org/topic/strict-non-coercing-expressions -- T.J. Crowder On Thu, Apr 13, 2017 at 6:58 AM, Darien Valentine

Re: Re: Strict Relational Operators

> It's reasonable for non-coercing === to work on different types, but what would a non-coercing + do with different types? It has to throw an error. Ah, didn’t catch that you were talking about non-relational operators as well. Assuming a strict `+` was still overloaded for string concatenat

Re: Re: Strict Relational Operators

On Wed, Apr 12, 2017 at 7:23 PM, Darien Valentine wrote: >> One common JS problem is NaNs ending up in unexpected places, and it's >> often difficult to trace back where they came from. Getting a type error >> instead of a NaN would be nice. > > I’m not sure this would help

Re: Re: Strict Relational Operators

NaNs ending up in unexpected places, and it's > often difficult to trace back where they came from. Getting a type > error instead of a NaN would be nice. > > I think this is a reasonable argument for being able to write > expressions with non-coercing operators, and this is why I

Re: Re: Strict Relational Operators

One common JS problem is NaNs ending up in unexpected places, and it's often difficult to trace back where they came from. Getting a type error instead of a NaN would be nice. I think this is a reasonable argument for being able to write expressions with non-coercing operators, and this is why

Re: Re: Strict Relational Operators

relational operators aren't (or weren't) on people's minds. :-) 2. To hear from implementers about the difficulty level of adding four more symbolic operators (`<=<`, `<==`, `>=>`, and `>==` or whatever they end up being). (I like my non-symbolic operators -- `lt`, `lte`, and suc

Re: Re: Strict Relational Operators

. On Apr 12, 2017 7:04 AM, "Darien Valentine" <valentin...@gmail.com> wrote: > > Personally I think `a < b` should just become a compile error if the > types are not number. > > Breaking stuff aside, I think this is an important point. The fact that > the LT/GT ope

Re: Re: Strict Relational Operators

> Personally I think `a < b` should just become a compile error if the types are not number. Breaking stuff aside, I think this is an important point. The fact that the LT/GT operators do work on strings is a source of bugs. As with default sort, I’ve seen code written a number of times

Re: Re: Strict Relational Operators

is with >> functions is an option because short-circuiting isn't an issue, both >> operands have to be evaluated by these relational operators anyway. So >> unlike the motiviations for infix functions or macros or whatever, we don't >> have that issue here. >> >> -- T.J

Re: Re: Strict Relational Operators

that solving this with > functions is an option because short-circuiting isn't an issue, both > operands have to be evaluated by these relational operators anyway. So > unlike the motiviations for infix functions or macros or whatever, we don't > have that issue here. > > -- T.J. Crowder &

Re: Re: Strict Relational Operators

Grr, there's always something. I forgot to mention that solving this with functions is an option because short-circuiting isn't an issue, both operands have to be evaluated by these relational operators anyway. So unlike the motiviations for infix functions or macros or whatever, we don't have

Re: Re: Strict Relational Operators

Very interesting stuff so far. My take on some options, organized into sections: * Solving it in userland * Using symbolic operators * Using functions * Using non-symbolic operators # Solving it in userland: Anyone wanting strict relational operators today can readily give themselves functions

Re: Re: Strict Relational Operators

: > Maybe every operator can have a non-coercing variant? > > One possible syntax is to have a modifier on operators > x = a (<) b (+) c (&&) (!)d; > if (x (!=) y) ... > > Another possible syntax is to have a modifier on expressions > x = #(a <

Re: Re: Strict Relational Operators

Maybe every operator can have a non-coercing variant? One possible syntax is to have a modifier on operators x = a (<) b (+) c (&&) (!)d; if (x (!=) y) ... Another possible syntax is to have a modifier on expressions x = #(a < b + c && !d) if #(x != y) ...

Re: Re: Strict Relational Operators

nctionality built in, but I wonder if it’d possibly be preferable to provide it through methods of one of the built-in objects, rather than as operators. Functions after all are more flexible. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Strict Relational Operators

s one of > them. > - > > Isiah Meadows > m...@isiahmeadows.com > > > On Mon, Apr 10, 2017 at 3:47 AM, T.J. Crowder > <tj.crow...@farsightsoftware.com> wrote: > > I'm sure there must have been discussions of adding str

Re: Strict Relational Operators

must have been discussions of adding strict relational > operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`, > and `>=`), but I'm not having a lot of luck finding those discussions. > Searching "strict relational > site:https://mail.mozilla.org/piper

Re: Strict Relational Operators

Hi T.J., I do not recall such a discussion. Please do start one! Thanks. On Mon, Apr 10, 2017 at 2:47 AM, T.J. Crowder < tj.crow...@farsightsoftware.com> wrote: > I'm sure there must have been discussions of adding strict relational > operators (e.g., non-coercing ones, the `=

Strict Relational Operators

I'm sure there must have been discussions of adding strict relational operators (e.g., non-coercing ones, the `===` versions of `<`, `>`, `<=`, and `>=`), but I'm not having a lot of luck finding those discussions. Searching "strict relational site: https://mail.mozilla.org/pip

Re: Re: New Assignment Operators (Not bit-wise OR)

Perhaps this proposal might fit with what you had in mind: https://esdiscuss.org/topic/proposal-for-a-null-coalescing-operator Been meaning to clean this up and submit it as an actual proposal since the idea is kind of simple: https://github.com/sirisian/ecmascript-null-coalescing-operator

Re: New Assignment Operators (Not bit-wise OR)

issue" with some of the ReactJS members at >> GitHub, and while saying this is a "stylus" thing, I disagree. It is more >> about not reiterating your code. >> >> Options could be: >> >> -tenaries - long & !clean codelines >> -default

Re: New Assignment Operators (Not bit-wise OR)

-default params (ES) , though it won't be a general use case > > There is already a lot of assignment, string and so on operators, but I > don't really seem any of them touch this, except maybe the bit-wise OR > assignment Operator. To read more about that, check these two links out: > &

Re: New Assignment Operators (Not bit-wise OR)

se = true > evalToTrue() > // outputs 'true' > }` > > `function() { > var false = false > evalToTrue() > // outputs the value of false > } > > `evalToTrue()` here means the XOR calculation. > > On Sun, Apr 17, 2016 at 6:30 PM, Jordan Harband <ljh...@gmail.com> wrote: &

Re: New Assignment Operators (Not bit-wise OR)

means the XOR calculation. On Sun, Apr 17, 2016 at 6:30 PM, Jordan Harband <ljh...@gmail.com> wrote: > This has been discussed many times before: > - https://esdiscuss.org/topic/operators-and > - https://esdiscuss.org/topic/logical-assignment-operators > - https://esdiscuss

Re: New Assignment Operators (Not bit-wise OR)

This has been discussed many times before: - https://esdiscuss.org/topic/operators-and - https://esdiscuss.org/topic/logical-assignment-operators - https://esdiscuss.org/topic/is-much-needed - https://esdiscuss.org/topic/please-add-orequal-operator If you read through these threads, you may

New Assignment Operators (Not bit-wise OR)

odelines -default params (ES) , though it won't be a general use case There is already a lot of assignment, string and so on operators, but I don't really seem any of them touch this, except maybe the bit-wise OR assignment Operator. To read more about that, check these two links out: https://

Re: Extending spread operators to work with numbers

defined > > > - easy to polyfill > > > - can't make mistake (consider [a...b] vs. [a,...b] - is it easy to see > > > difference?) > > > > > > Disadvantages: > > > - longer than custom syntax > > > > > > On 24 Jan 2016 7:11 am,

Re: Extending spread operators to work with numbers

Actually, I beg to differ. Recall that this is valid syntax: > > 1.. toString(16); > > Furthermore, maintaining a 3-dot notation stays consistent with the rest > and spread operators, both of which already overload each other. For sake > of clarity for this discussion, I'll call this

Re: Extending spread operators to work with numbers

to differ. Recall that this is valid syntax: >> >> 1.. toString(16); >> >> Furthermore, maintaining a 3-dot notation stays consistent with the rest >> and spread operators, both of which already overload each other. For sake >> of clarity for this discussio

Re: Extending spread operators to work with numbers

't make mistake (consider [a...b] vs. [a,...b] - is it easy to see > > difference?) > > > > Disadvantages: > > - longer than custom syntax > > > > On 24 Jan 2016 7:11 am, "John Gardner" <gardnerjo...@gmail.com> wrote: > >> *This has all

Re: Extending spread operators to work with numbers

On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjo...@gmail.com> wrote: > Probably a stupid idea, and I can see it already being brought up several > times... but why not extend spread operators to work with numeric ranges? > > let a = [ 0 ... 3 ]; > // Expands to: [ 0, 1,

Re: Extending spread operators to work with numbers

nd spread operators, both of which already overload each other. For sake of clarity for this discussion, I'll call this one the "range operator". *I think this is one of those issues where the benefit of any new syntax > here does not pay for its complexity costs.* I don't foresee this

Re: Extending spread operators to work with numbers

lready being brought up several > times... but why not extend spread operators to work with numeric ranges? > > let a = [ 0 ... 3 ]; > // Expands to: [ 0, 1, 2, 3 ] > > This wouldn't be a groundbreaking feature, but it would allow better > readability when plotting a range of values:

Re: Extending spread operators to work with numbers

ion. Then the decimal component, if any, would be ignored, and the resulting value used. *> And what about parsing it next to a "regular" spread operator?* "Regular" spread operators should take precedence. The order of evaluation would be like this: let range = [ ...[1, 3] ... ...[

Extending spread operators to work with numbers

Probably a stupid idea, and I can see it already being brought up several times... but why not extend spread operators to work with numeric ranges? let a = [ 0 ... 3 ]; // Expands to: [ 0, 1, 2, 3 ] This wouldn't be a groundbreaking feature, but it would allow better readability when plotting

Re: Re[2]: Operators overriding

That's almost implementing its own runtime system just to emulate operator overloading, to be honest. On Mon, Dec 28, 2015, 17:10 /#!/JoePea wrote: > I just read this interesting article: > http://www.2ality.com/2011/12/fake-operator-overloading.html?m=1 > > Wow. What

Re: Re[2]: Operators overriding

ncorrect? > > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote: >> >> I dislike this proposal. >> 1 It is not very good to limit overrideable operators to value classes. >> 2 It is not very good to have a lot of custom operators, it will break >&

Re: Re[2]: Operators overriding

. making `a + b` or `a | >> 0` >> > more flexible would also make them slower. Is this incorrect? >> > >> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote: >> >> >> >> I dislike this proposal. >> >> 1 It i

Re: Re[2]: Operators overriding

incorrect? > > > > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote: > >> > >> I dislike this proposal. > >> 1 It is not very good to limit overrideable operators to value classes. > >> 2 It is not very good to have a lot of custom op

Re: Re[2]: Operators overriding

y benefits of * paren-free function invocation * non-member, postfix function call syntax, aka `::` And finally, any discussion about the perceived "mental tax" of operators would be incomplete without a reference to the definition of the `+` operator in ECMAScript 2016[1]. Ever tried explaini

Re: Re[2]: Operators overriding

like e.g. making `a + b` or `a | >>> > 0` >>> > more flexible would also make them slower. Is this incorrect? >>> > >>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kola...@mail.ru> wrote: >>> >> >>> >> I dislik

Re: Re[2]: Operators overriding

On Mon, Dec 28, 2015 at 10:19 AM, Alexander Jones wrote: > `[] + {}` That's an odd use case. I've never used it myself. Straight face not possible. x] ___ es-discuss mailing list es-discuss@mozilla.org

Re: Re[2]: Operators overriding

I just read this interesting article: http://www.2ality.com/2011/12/fake-operator-overloading.html?m=1 Wow. What iteresting "fake" overloading. Check out the `new Point(1, 2) + new Point(3, 4) + new Point(5, 6)` example. On Mon, Dec 28, 2015 at 11:36 AM, Sander Deryckere

Re: Re[2]: Operators overriding

On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck wrote: > Who would think not knowing what `a+b` could do as a pitfall? /s > > I am not a big fan of overloading though, since it presents more mental > complexity as they map to functions without looking like function calls.

Re: Re[2]: Operators overriding

I'm kind of on the fence about it. `let result = matrix1.multiply(matrix2)` works for graphics, but `var result = matrix1 * matrix2` could be nice. Now that I think about it, I think I'll fall over onto the +1 side of the fence, because one of the things I love about JavaScript is how flexible it

Re: Re[2]: Operators overriding

There are so many places where overloading would be useful., even between different data types: * adding vectors * multiplying vectors with matrices * multiplying vectors with numbers * multiplying or adding matrices * adding (or subtracting) date objects (to get a time difference) Certainly in

Re: Re[2]: Operators overriding

aka `::` > > And finally, any discussion about the perceived "mental tax" of operators > would be incomplete without a reference to the definition of the `+` > operator in ECMAScript 2016[1]. Ever tried explaining to beginners what the > result of `[] + {}` is, while keeping

Re: Re[2]: Operators overriding

I dislike this proposal. > 1 It is not very good to limit overrideable operators to value classes. > 2 It is not very good to have a lot of custom operators, it will break > code readability and will allow more efficient obfuscration. > 3 I think that most of binary non-assigning operat

Re[2]: Operators overriding

I dislike this proposal. 1 It is not very good to limit overrideable operators to value classes. 2 It is not very good to have a lot of custom operators, it will break code readability and will allow more efficient obfuscration. 3 I think that most of binary non-assigning operators must return

Re: Operators overriding

presentation from Brendan Eich here: http://www.slideshare.net/BrendanEich/value-objects2 Regards, Sander 2015-12-18 21:24 GMT+01:00 KOLANICH <kola...@mail.ru>: > Hello. What do you think about overriding operators using proxies? > > For example > function A(r=""){ >

Operators overriding

Hello. What do you think about overriding operators using proxies? For example function A(r=""){ this.rep=r; return new Proxy(this,{operators:{"+":function(a,b){return new A(a.rep+"+"+b.rep);}}}); } let a=new A("a"), b=new A(&

Re: UInt8ClampedArray Bitwise operators?

I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it. Breaking the Web would be an understatement. On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: ES2015 already has element accessor

Re: UInt8ClampedArray Bitwise operators?

Oh. Pardon my ignorance. Misunderstood the idea. On Wed, Aug 12, 2015, 23:19 Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 12, 2015, at 7:30 PM, Isiah Meadows wrote: I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it.

Re: UInt8ClampedArray Bitwise operators?

wrote: SIMD types have bitwise operators, but SIMD.js exposes just fixed-size vectors that are optimized to what hardware can optimize certain operations for. A future extension (the long SIMD API) may operate on whole arrays. I wouldn't recommend using SIMD.js unless you really feel like

Re: UInt8ClampedArray Bitwise operators?

of a byte array so I was hopeful. And it seems more generally useful than things like SIMD types. Thanks, Michael McGlothlin Sent from my iPhone On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg little...@chromium.org wrote: SIMD types have bitwise operators, but SIMD.js exposes just fixed

Re: UInt8ClampedArray Bitwise operators?

ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the

Re: UInt8ClampedArray Bitwise operators?

On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: Operator overloading or value types might make it look a lot prettier some day (though iirc element assessor overloading was off limits), but you could get pretty far by baking it into a compile-to-js language.

Re: UInt8ClampedArray Bitwise operators?

Also `instanceof` overloading via `Symbol.hasInstance` On Wed, Aug 12, 2015 at 10:44 AM, Daniel Ehrenberg dehrenb...@chromium.org wrote: On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: Operator overloading or value types might make it look a lot prettier some

  1   2   >