Re: Function composition vs pipeline

Straw man. The problem is variables named h, f and g, not the use of a composition operator. On Sun, 11 Mar 2018 at 07:37, kai zhu wrote: > @peter, put yourself in the shoes of a senior-programmer responsible > for overseeing an entire web-project. the project is @ the >

Re: Suggestion: Destructuring object initializer.

The difference between `{...a, ...b}` and `Object.assign({}, a, b)` is the same as the difference between `[a, b]` and `new Array(a, b)`. The latter cases (correct me if I'm wrong) rely on dynamic lookup of names and methods, whereas the former cases, as syntactical constructs, have statically

Re: async/await -> await/async: a simpler, less error-prone async syntax

FTR, TypeScript and Flow (I assume) know when the static type of a function call (or any other expression that evaluates to a Promise) is a Promise, and if you try to use it as if it wasn't, it will almost surely be a type error. On 12 February 2018 at 10:27, Алексей wrote: >

Re: Suggestion: Infix operators/functions

Time to put infix operators into TypeScript, first, then? On Sat, 3 Feb 2018 at 04:25, kdex 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 > been a bad idea at

Re: Partial Expression proposal

The real JavaScript 'character wall'. On 27 December 2017 at 21:30, Sebastian Cholewa < sebastian.chol...@interia.eu> wrote: > On PC writing “§” character wouldn’t be convenient, as it’s not on > keyboard. One would has to copy and paste it. I see this as problematic. > Writing code should not

Re: Allow any quoted string to be multiline?

are > brackets). > > [image: image.png] > > > On Mon, 18 Dec 2017 at 10:09 Alexander Jones <a...@weej.com> wrote: > >> I question why 3 forms of quotation exist in modern codebases. Just use >> template literals. The only reason not to is resistance to change. ESL

Re: Allow any quoted string to be multiline?

I question why 3 forms of quotation exist in modern codebases. Just use template literals. The only reason not to is resistance to change. ESLint will autofix for you. On 18 December 2017 at 09:47, J Decker wrote: > > > On Mon, Dec 18, 2017 at 3:08 AM, Claude Pache

Re: async/await -> await/async: a simpler, less error-prone async syntax

> with the added bonus of transparently allowing sync functions to be converted to async functions without fundamentally affecting consumer calling code. It does fundamentally affect calling code if the calling code reaches outside of its local variables. The state of the world around you might

Re: How it feels to learn JavaScript in 2016

They’re not even *objects*, let alone regular objects! :) Making every new addition to the language be a subtype of object just creates a worse language. Given the constraints and requirements it was the right choice to make symbol a new primitive. Technically it “broke the web”, like literally

Re: Array.prototype.remove(item)

Small Sets could maybe be represented without the tree? And everything you say about SIMD could be done too when the set has a viable homogeneous type. On Fri, 10 Nov 2017 at 14:26, T.J. Crowder wrote: > On Fri, Nov 10, 2017 at 2:17 PM, Isiah Meadows >

Re: Syntax is the Problem

This is projective editing. See for example https://www.jetbrains.com/mps/ On 5 November 2017 at 13:22, Michael Lewis wrote: > Raul-Sebastian Mihăilă just made a post here about some mixin syntax. I > didn't read it (sorry). > > But, it got me thinking about a concept I've been

Re: How it feels to learn JavaScript in 2016

This appears to be borderline trolling. I can assert with confidence that ES6+ is bringing clear wins in maintainability and developer efficiency. If your colleagues are writing ‘brittle’ code in ES6 I’d argue it’d be worse in ES5 on average. (Also a mailing list is a great way to get FUD into a

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

the original question, > I > > gave my opinion and reason in brackets. If the reader prefers a different > > way for their own reasons, fine - I would just expect them to give their > own > > reasons for superseding my reasons... > > > > On Wed, 18 Oct 2017 at 14:34 Alex

Re: styleguide sanity-check for tc39 language-proposals to address javascript-fatigue

The beauty of (coding) standards is that there are so many to choose from. :) IMO it’s a false dichotomy though. A respected and credible group of language contributors should pool some energy together and ratify some opinionated best practices, a la the C++ Core Guidelines and PEP-8. No, it’s

Re: Make comma at the end of line optional

IIFEs start with a (. Putting line breaks before certain expressions can help improve clarity. Your mind is made up but I have to protest. ASI *sucks*. And the extra cognitive overhead it causes is utterly pointless. If you don’t want to type them, why not program your editor to actually insert ;

Re: super return

Perhaps if the nested function is lexically inside such super function it can be fair game and actually quite powerful and liberating. Unconstrained 'upleveling' is IIRC valid in such wonderful languages as Tcl. This unverified fact is presented without opinion :D On Tue, 29 Aug 2017 at 16:57,

Re: Proposing a conditional assignment (or equals) operator

For what it's worth, doubling down on a design that exposes such poor choices wouldn't necessarily be a bad thing ;) On Wed, 16 Aug 2017 at 02:56, kai zhu wrote: > this proposal is not as useful as you would think. when integrating > with api's and modules not written by

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

ring is > required, despite the MDN article. I wouldn't oppose an equivalent > `Array.prototype.toMap` and `Map.fromIterable`, I would just hardly ever > use it > > On Sun, 13 Aug 2017, 10:33 p.m. Alexander Jones, <a...@weej.com> wrote: > >> Honestly, promoting the u

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

an object's keys and values from any iterable. >>> >>> I also was just thinking that both can perfectly coexist with >>> `Array.prototype.toObject(keyFromElement[, valueFromElement])` which >>> has the advantage of chain-ability after array transformation method

Re: Re: Array.prototype.toObjectByProperty( element=>element.property )

`Map.fromIterable` takes an iterable of values, and a key function. Would a `Map.prototype.toIterable` return only the values - that's already `Map.prototype.values`? It feels like there is a symmetry issue here. Perhaps this could be `Map.fromValues`? Worth also remembering that compressing

Re: Re: Stage 0 Proposal: Extensible Collection Literal

ets to a state we can consider it. > > On Sun, Jul 30, 2017, 12:04 Alexander Jones <a...@weej.com> wrote: > >> Hey Isiah >> >> Good shout - definitely worth connecting pattern matching/destructuring >> to the same concept. >> >> Let's assume `#{

Re: Re: Stage 0 Proposal: Extensible Collection Literal

Hey Isiah Good shout - definitely worth connecting pattern matching/destructuring to the same concept. Let's assume `#{}` is kept, for the avoidance of bikeshedding: ```js const map = Map#{42: "the answer"}; const #{42: fortyTwo} = someMap; // or? const {[42]: fortyTwo} = someMap;

Stage 0 Proposal: Extensible Collection Literal

As a follow-up to https://esdiscuss.org/topic/map-literal I've finally (2 years? Really?) written up a proposal for extensible collection "literal" syntax (for Map, Set, Immutable.List, etc.) https://github.com/alex-weej/es-extensible-collection-literal Thanks Alex

Re: Removal of language features

Removing things also frees up syntax and names for future extensions. Never removing features is simply unscalable, and it's only going to accelerate JS's demise! I still think version pragmas are probably worth exploring to mitigate this, while not 'breaking the web' is a stated goal. Alex On

Re: A twist on functional operatorsr

I think JavaScript has reached "peak token"... I also wanted to use the # for generic map/list literal syntax: https://esdiscuss.org/topic/map-literal On 15 July 2017 at 04:24, Isiah Meadows wrote: > Few nits inline: > > - > > Isiah Meadows > m...@isiahmeadows.com >

Re: Naming convention for multi-word identifiers with initialisms

at 13:07, Alexander Jones <a...@weej.com> wrote: > Occasionally this comes up when deciding on a spelling for something. > There are numerous examples in ECMAScript and other Web standards that seem > to defy the most uniform convention: > > * `JSON` vs. `Json` >

Re: New Array Functions

`array.get(-1)` could have the desired semantics (and be nicely symmetric with Map), but actually in other languages (e.g. Python) I find that this "trick" with negative numbers can lead to a surprising (and scary) propagation of bugs, where array bounds checking is not correctly done. Actually

Re: Naming convention for multi-word identifiers with initialisms

at 16:37, Domenic Denicola <d...@domenic.me> wrote: > https://w3ctag.github.io/design-principles/#casing-rules > > > > *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of > *Alexander > Jones > *Sent:* Tuesday, July 11, 2017 08:07 > *To:*

Naming convention for multi-word identifiers with initialisms

Occasionally this comes up when deciding on a spelling for something. There are numerous examples in ECMAScript and other Web standards that seem to defy the most uniform convention: * `JSON` vs. `Json` * `toJSON` vs. `toJson` * `XMLHttpRequest` vs. `XmlHttpRequest` * `DOMElement` vs.

Re: Extends expression performs differently on Edge

`y, z` is comma operator, no? On Fri, 26 May 2017 at 08:57, Gareth Heyes wrote: > ```javascript > class y{}class z{} > class x extends y, z{}/alert(1)/+alert(2) > ``` > > Edge seems to allow non-standard syntax here. I guess to allow you to > extend multiple

Re: Officially support a shebang line

It doesn't make any sense. The shebang is a UNIX way of declaring the interpreter for an executable script, not for hinting your syntax highlighter. If your file is not executable (as in, it can't be run with `./filename`, it shouldn't have a shebang). On 19 May 2017 at 02:44, Jan Krems

Re: Object.isEqual

adhered to except near interchange points where JSON makes sense. > (And even then, it's common to accidentally step outside of it, for example > by having something overflow to Infinity or accidentally produce a NaN.) > > On 05/01/2017 02:04 PM, Alexander Jones wrote: > > I hear this argument

Re: Object.isEqual

I hear this argument a lot but it strikes me with cognitive dissonance! JSON defines a very intuitive notion of object value-semantics - whether the serialized JSON is an equivalent string. Granted that many value types are not supported by JSON, but it's a trivial generalisation. Let's just give

Re: Re: Strict Relational Operators

Personally I think `a < b` should just become a compile error if the types are not number. TypeScript? If you want to also check that they are both number (that's surely what we mean here and not that they are both string!) and return `false` if not, that's a separable concern which should not be

Re: Proxies fail comparison operator

I would really hope that `===` can never be trapped. So much code would break! (Then again, I thought that about toString... :/) On Fri, 31 Mar 2017 at 15:21, Michael Lewis wrote: > Proxies do not reflect internal slots (Oriol) > > > You really don't *want* proxies to equal

Re: An alternate way of integrating integers

Not been following this, but given that JSON supports arbitrary precision *numbers* (that JS cannot decode), not just integers, my hunch is that we could/should explore this option too! Python seems to do pretty well (right?) with integers being bignum (and, aside, all strings being Unicode,

Re: Standardizing conditional try/catch

matching is to conditionals as async/await is to async tasks - > it lifts the logic from fairly imperative, low level form to a high > level, declarative form, with only a small loss of low-level control. > - > > Isiah Meadows > m...@isiahmeadows.com > > > On Mon, M

Re: Standardizing conditional try/catch

Any future matching syntax would clearly support the special cases people want to codify now. It might be that the best possible syntax is lost, but e.g. ASI alone is probably a much bigger cause of syntax showstoppers to be worried about. IMO, let it build up, then we can start thinking about a

Re: Enable async/await to work on functions that don't just return promises.

Required reading for anyone who wants to be so... opinionated ;) http://joeduffyblog.com/2015/11/19/asynchronous-everything/ On Sun, 26 Feb 2017 at 16:35, Florian Bösch wrote: > On Sun, Feb 26, 2017 at 5:30 PM, Codefined > wrote: > > I'll be

Re: Enable async/await to work on functions that don't just return promises.

Florian, you shouldn't pass the argument of explicit vs implicit coroutines off as being so simple. There are many compelling arguments for both! Please Google them! On Sun, 26 Feb 2017 at 00:01, Florian Bösch wrote: > On Sat, Feb 25, 2017 at 11:55 PM, Codefined

Re: name anonymous functions on property assignments

Just for a bit of context, can you elaborate on how this broke your code? Thanks On 27 January 2017 at 16:56, Jordan Harband wrote: > I'd have an objection. Function name inference has already broken my code > - luckily only tests so far, that i know of - and doing it more

Re: Idea: Reflect.hasExternalReference

to there, but exposing reference count in any way seems dubious to me! Alex On Sun, 15 Jan 2017 at 16:25, T.J. Crowder <tj.crow...@farsightsoftware.com> wrote: > I'm assuming that Alexander Jones means that you'd document you require an > immutable, and thus not need to check, and just happily use

Re: Idea: Reflect.hasExternalReference

IMO we should explore generalising syntax for map literals and object destructuring, bringing something like Immutable.Map into the spec, and thus bringing JS into a new modern era. Otherwise people who care about this stuff will just continue to move to other languages like ClojureScript in

Re: Proposal: Improve syntax for inline anonymous class instantiations

Hi Igor With `super()` and closure binding of the anonymous class `constructor` (as with all class methods) you can basically solve your problem of constructor arguments appearing in the wrong place: ``` this.add( new class extends ArrayView { constructor() { super("items",

Re: Weak Reference proposal

Please correct me Isiah/Steve - but I think the problem Steve is talking about is *cross-process* cycles. Without an inter-process protocol to express the referencing graph, or otherwise negotiate cycles for GC, you'll never have a way to reclaim them. Each side thinks the other side is still

Re: Immutable const?

IMO we should unblock anything that stands in the way of ergonomics when using new product type types, other than Object. If I can write code using Immutable.Map as succinctly as I can Object then we're half way there. See https://esdiscuss.org/topic/map-literal for discussion on generalized map

Re: Ranges

IMO this is quite unnecessary syntax sugar. Python has everything you could need here without special syntax. On Wed, 14 Dec 2016 at 16:55, Jeremy Martin wrote: > While slightly more verbose, the previously suggested `...` syntax does > have a superficial consistency with the

Re: Object.equals() and Object.clone()

Object has this unfortunate complication of prototypes, i.e.: ``` const objA = {foo: 1, bar: 2}; const objB = Object.create(objA); equals(objA, objB) === ? ``` And also there is metadata on each property that can vary (one object has a property which is configurable, and the other has the same

Re: Proposal: Symbol.templateTag

As promised (to myself!) I've written a stage-0. https://github.com/alex-weej/es-symbol-template-tag Your feedback is greatly appreciated. Thanks On 18 November 2016 at 00:30, Alexander Jones <a...@weej.com> wrote: > OK, I was thinking about this incorrectly and I think you

Re: Proposal: Symbol.templateTag

ateTag is a new symbol, guaranteed > unequal to any prior value, how can introducing it, and new behavior > conditional on it, change any existing behavior? > > > > > On Wed, Nov 16, 2016 at 5:02 PM, Alexander Jones <a...@weej.com> wrote: > >> Hi es-discuss! >

Proposal: Symbol.templateTag

Hi es-discuss! Template tags are a great feature with many novel applications, IMO approaching macro-level expressiveness. But due to their nature in this context, it's helpful if tags are named quite tersely. Unfortunately, if you have existing API, this can be challenging. Let's say I have a

Re: Ranges

+1000 Classic feature creep with basically zero application. On Thursday, 3 November 2016, Isiah Meadows wrote: > Could we just *not* have a `String.range`? > > 1. Needing a list of alphabetically sorted characters is a bit niche, even > in the Latin alphabet. > 2. It's

Re: Proposal: Array.prototype.accumulate and Array.prototype.accumulateRight

Can we please start talking about Iterators already? The Python community are laughing at us! Widening the Array prototype is like putting lipstick on a pig... On Thursday, 27 October 2016, Bergi wrote: > Mark M. Young wrote: > >> I am proposing a replacement for

Re: Symbol description inference

IMO, the real problem that needs solving is macros. Macro-based definition of a symbol could trivially reuse the name. On Tuesday, 25 October 2016, Allen Wirfs-Brock wrote: > Function name inferencing is possible because function definitions are all > syntactic special

Re: JSON.stringify

Maybe we should just make U+2028 and U+2029 valid in JS then? What other productions in JSON are invalid syntax in JS? On Thursday, 29 September 2016, Mike Samuel wrote: > On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla > > wrote:

Re: JSON.stringify

Samuel <mikesam...@gmail.com> wrote: > Without CDATA you have to encode script bodies properly. With CDATA you > have to encode script bodies properly. What problem did CDATA solve? > > On Sep 28, 2016 8:03 PM, "Alexander Jones" <a...@weej.com > <javas

Re: JSON.stringify

o s/\]\]>/]]>]]/g. > > On Sep 28, 2016 2:32 PM, "Alexander Jones" <a...@weej.com > <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote: > >> That's awful. As you say, it's an antipattern, no further effort should >> be spent on this. JSON produced

Re: JSON.stringify

aying "it's antipattern, don't do this" we will not make old > vulnerable code go away. And we have a very good way to stop people from > shooting their own feet - for free. > > On 28 Sep 2016 8:31 p.m., "Alexander Jones" <a...@weej.com> wrote: > > That'

Re: JSON.stringify

That's awful. As you say, it's an antipattern, no further effort should be spent on this. JSON produced by JavaScript has far more general uses than slapping directly into a script tag unencoded, so no-one else should have to see this. Also, there are many other producers of JSON than JavaScript.

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

Yes, please don't special case for-of handling, it's nicely expressed in terms of other concepts. On Sunday, 25 September 2016, saam barati wrote: > It seems like Jordan's suggestion is what you want then. > > - Saam > > On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra

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

On 15 August 2016 at 19:20, Allen Wirfs-Brock wrote: > > Because Symbol does not have a syntactic literal form, some sort of > invocation is required to acquire a new unique primitive Symbol value. > That is where you get the potential for confusion between `Symbol()` and

Re: Function constants for Identity and No-op

Those spellings don't help when trying to visually parse a bunch of code which already largely consists of dense punctuation, though, IMO. On Wednesday, 10 August 2016, Tab Atkins Jr. wrote: > On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman

Re: Operating with arbitrary timezones

ssible representation of it. Perhaps some class or function other than `Date` can produce `LocalDatetimeComponents` objects, maybe one that supports leap seconds in applications that actually need it. Alex On 6 August 2016 at 00:08, Jon Zeppieri <zeppi...@gmail.com> wrote: > > > O

Re: Operating with arbitrary timezones

Don't confuse timezones with timezone offsets. They are different concepts. On Friday, 5 August 2016, Jon Zeppieri <zeppi...@gmail.com> wrote: > > > On Fri, Aug 5, 2016 at 5:58 PM, Alexander Jones <a...@weej.com > <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wr

Re: Operating with arbitrary timezones

ving arithmetic on this hypothetical new > set of components (arithmetic is one of the most useful things about date > time libraries) but that's details to be explored later and I guess this is > getting off track from the original proposal here. > > On Fri, Aug 5, 2016 at 1:01 PM, Al

Re: Operating with arbitrary timezones

I would object to your suggestion on the grounds that, as they stand, Date objects represent exact points in time, with no ambiguities, and in many cases that's exactly what you need. Once you endow them with a timezone offset they cease to represent points in time, but rather more points in

Re: Suggestion: Object.symbols

Well, a map is more often of dynamic size, mapping from one specific type T to another specific type U. (Of course, either can be variants.) An object is a bag of properties of fixed size, with keys of type string|symbol, values of a type specific to the property, metadata from the property

Re: Suggestion: Object.symbols

In my opinion, the consensus appears to be moving towards treating Objects like records, structurally typed bags of properties that don't change shape over their lifetime, and are thus statically analysable. See TypeScript's approach for a justification. On Thursday, 16 June 2016, doodad-js Admin

Re: Suggestion: Object.symbols

Not in general, just for map-like usages, i.e. if you have an object where the keys are not static, you probably would be better served by a map. The problem with those functions you describe is that there are a large combinatorial set of them - did you want configurable, own, non-enumerable

Re: Suggestion: Object.symbols

Question is why would you actually want this when you have `Map`? I consider all of the 'get some arbitrary subset of properties from an object' use cases obsoleted by `Map`. But maybe I'm missing something obvious or not-so-obvious...? Cheers Alex On Wednesday, 15 June 2016, doodad-js Admin

Re: Array.prototype.includesAll

There is a precedent here from set theory. A.includesAll(B) is really the equivalent of: A is a superset of B or otherwise put: B - A = empty set Hence, if B is the empty set, then it is indeed true for all sets A. Cheers On Tuesday, 14 June 2016, Shahar Or

Re: New Set.prototype methods

Most of these would be better off as generic iterable-consuming, iterator-producing functions. You know, Single Responsibility Principle, and all that. As for the rest, IMO union, intersect, and the zoo of other missing set theory operators would probably be better off as multiple dispatch

Re: JavaScript Language feature Idea

This is why we can't have nice things... Literally anything we do with the language *at all* can collide with libraries. Introducing new syntax? Code that was using eval and throwing syntax errors is now behaving differently and you 'broke the web'... Adding a `Symbol.last` method to `Array#`?

Re: Add support for arbitrary code inside template tags without the 'do' keyword

The two code samples you posted are equivalent (modulo the obvious mistake). AFAIU there is still only a single parsing pass for template strings. On Tuesday, 12 January 2016, /#!/JoePea wrote: > The thing with template strings is that they are used at runtime. This > could be

Re: Re[2]: Operators overriding

Who would have thought using completely un-semantic idioms such as |0 and !! would lead to issues down the line? /s On 28 December 2015 at 14:50, Nicolas B. Pierron < nicolas.b.pier...@mozilla.com> wrote: > This is right, currently code such as "asm js" rely on "a | 0" and > "+a" to force a type

Re: Re[2]: Operators overriding

ents more mental > > complexity as they map to functions without looking like function calls. > > > > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <a...@weej.com> wrote: > >> > >> Who would have thought using completely un-semantic idioms suc

Re: Propose simpler string constant

What optimizations? On Thursday, 17 December 2015, Isiah Meadows <isiahmead...@gmail.com> wrote: > @Alex Those languages have this thing called static types, which enable > many of those optimizations. > > On Thu, Dec 17, 2015, 04:09 Alexander Jones <a...@weej.com > <

Re: Propose simpler string constant

I think we can do better than to follow C#'s lead, if that's the case. I don't see what the point in `Color.Red - Color.Green` is. Languages like Rust, Swift, OCaml are providing full Algebraic Data Types that approach this whole domain from a better level. Also, I don't like the idea of

Re: Propose simpler string constant

TypeScript has this already, so I'm sure we can learn a thing or two from their implementation. On 15 December 2015 at 19:56, Andrea Giammarchi wrote: > Jordan AFAIK you can't have undefined const declaration so your concern is > unfounded. > > However, I'm pretty

Re: The "Pipeline" Operator - Making multiple function calls look great

I wonder whether we've reach that point in the language where trying to reuse the same old tokens over and over again in new combinations is getting untenable. It's a long road to APL... On 11 December 2015 at 15:23, Gilbert B Garza wrote: > Rick: I would imagine some

Re: The "Pipeline" Operator - Making multiple function calls look great

Why not just have a rule that the pipeline operator consumes unary functions, and reuse existing bind idioms, or a future bind syntax? That seems like a proper separation of concerns to me. As with those future bind syntax proposals, the idea of just sticking a token somewhere within an

Re: Map literal

; wrote: > With that syntax, I'm not even sure it's necessary. It's not much more > concise than a list of 2-tuples. Don't quite see the benefit the other than > a few characters. > > On Sat, Nov 28, 2015, 22:22 Tab Atkins Jr. <jackalm...@gmail.com> wrote: > >> On Thu,

Re: String.prototype.padLeft / String.prototype.padRight

I see about as little use case for this as `String.prototype.blink`. Date/hours is better solved with zero padding formatting, not just padding out the already stringified number (think negative values -42). Same applies to filenames for lexicographical sort. Fixed length fields in wire

Re: An update on Object.observe

In my opinion, the fundamental record type we build our JS on should be getting dumber, not smarter. It feels inappropriate to be piling more difficult-to-reason-about mechanisms on top before reeling in exotic host objects. With Proxy out of the bag, I'm not so hopeful for the humble Object

Re: Map literal

Keys(target, pairs) { > for (const [key, value] of pairs) { > target[key] = value > } > return target > } > > extend class Object { > static [Symbol.fromHash](pairs) { > return SetKeys({}, pairs) > } > > static null(pairs) { > retu

Re: Map literal

ing. At this point I don't know what a raw `#{}` should produce... There may be a better use case for it in the future, horrible ASI complexities notwithstanding. Alex On Wednesday, 28 October 2015, Herby Vojčík <he...@mailbox.sk> wrote: > > > Alexander Jones wrote: > >&

Re: Map literal

= Map#{"foo": 42}; m.get("foo") === 42; m.set("bar", 43); ``` Would you agree? On Wednesday, 28 October 2015, Alexander Jones <a...@weej.com> wrote: > Hi Herby > > Agree with your concerns about symmetry with object literals, but many of > the

Re: Map literal

o', 2: 8}; > ``` > > Will not have entries in the order `[[1, 6], ['bar', 'Hello'], [2,8]]` but > instead `[[1,6], [2,8], ['bar','Hello']]`. > > This means that possible future destructuring of a Map will be harder to > reason about. > > > 2015-10-28 2:21 GMT+01:00 Al

Re: Map literal

ve lexical ordering of entries. The fault is completely > mine. Sorry. > > I like this proposal as it is extensible and not that noisy in syntax. > Using the `#` for this doesn't > seem like a bad idea either. People coming from Erlang will be familiar > with this as well. > >

Re: Map literal

Map#{"foo": 42}` I don't see much difference with `new >> Map([['foo', 42]])`. >> >> Since you can pass expressions there, it's already possible to do it with >> current syntax. There is only a bunch of extra brackets(`[` and `]`) that I >> don't like.

Re: Map literal

I agree this is pretty important. Using actual maps really frees up a lot of complexity, but the syntax is cumbersome to say the least. Whatever the decided syntax, bare words as string keys is a really bad idea IMO. The key syntax should be parsed as an expression, like the values are, and like

Re: Map literal

, though admittedly constructor call for the ES6 types would be a partial improvement. On Wednesday, 28 October 2015, Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones <a...@weej.com > <javascript:;>> wrote: > > I agree t

Re: Map literal

ies({ a: 'b', b: 'c' }))`. > > On Tue, Oct 27, 2015 at 4:36 PM, Alexander Jones <a...@weej.com > <javascript:_e(%7B%7D,'cvml','a...@weej.com');>> wrote: > >> I agree this is pretty important. Using actual maps really frees up a lot >> of complexity, but the sy

Re: Decorators for functions

OK, appreciate that. Let's explore this problem space: Why not have syntax to set a property descriptor onto a class or object literal? In Python, this is implicit. For example (IIRC): ```python class Foo: prop = some_descriptor x = 100 ``` Both `Foo.x` and `Foo().x` (instance attribute

Re: Decorators for functions

eate an object to unpack it ... why not ... named functions? why not >> ... I'm used to write `{method: function method() {}}` for debugging sake >> and I like named functions but going even more dirty with the workaround >> maybe an array to unpack would make it less maintainabl

Re: Decorators for functions

I've become convinced by this thread that we don't need this. Other languages where decorators are useful and prevalent don't have the expressivity JS has, particularly regarding dynamism and function expressions. JS `class` is an awkward case due to not supporting non-method members, but I think

Re: Return value of forEach

You mean to say you *don't* have ```js var undefined = [].forEach(Array.prototype.forEach.call); ``` at the top of every file!? On Friday, 16 October 2015, Niloy Mondal wrote: > > That'd be a compatibility break. > > Ugh... you mean people actually depend on

Re: Exporting Symbols

Unless of course you needed to export a "features" AND support this magic symbol. On Thursday, 15 October 2015, Ron Buckton wrote: > Wouldn’t this work? > > > > our-symbols.js: > > ```js > > export const SpecialSymbol = Symbol("SpecialSymbol"); > > ``` > > > >

Re: Curried functions

Too late, `add(a)` already returns `a + undefined`. No reason why `const add = curry((a, b) => a + b)` couldn't work though? Arrow functions have a length property AFAIK. On Thursday, 15 October 2015, Yongxu Ren wrote: > How about making arrow function curry by default? >

Re: Swift style syntax

rdi < >>>>> f.bagna...@gmail.com >>>>> <javascript:_e(%7B%7D,'cvml','f.bagna...@gmail.com');>> wrote: >>>>> >>>>>> I don't think there's much value in this. Also sort is a bad example >>>>>> because i

  1   2   >