Re: Re: Proposal: Placeholder operator

[dante federici]

Any reason you don't like the empty space with a comma? I also don't, but
that's what it is now:

```js
arr.map(( , index) => ...)
```

Also wouldn't mind ? or *, since I associate ! with "not" as a unary
operator, but "*" isn't a unary in JS.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: How to prettify output of objects in the console, when using get/set, like browsers do?

[dante federici]

So, it actually all works as you'd expect when using properties on the
class itself:

```js
```

In that polyfilll, it actually is making x, y, z, and w private fields:
https://github.com/trusktr/geometry-interfaces/blob/41d8cca9c0b4e4ab7afbb9a3a1d02ca94d048f3f/src/DOMPoint.js#L2
```js
const _ = o => {
if (!privatesMap) {
privatesMap = new WeakMap
let privates = {}
privatesMap.set(o, privates)
return privates
}
else {
let privates = privatesMap.get(o)

if (privates === undefined) {
privates = {}
privatesMap.set(o, privates)
}

return privates
}
```


So, the new instances _never_ have a visible property for the console to
display. Compare to:

```js
class Test {
constructor(x) { this._x = x }
get x(){ return this._x; }
set x(v){ this._x = v; return v; }
}
console.log(new Test(123));
> Test { x: 123 }
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal for faster this assignments in constructor functions

[dante federici]

I can see that, although I'm struggling to come to that conclusion if I saw
that block of code fresh. I don't think it would be immediately clear,
though. In your interpretation of "this has 5 arguments", what would you
expect them to be? `constructor(x, y, a, b, c)`? Just prepend them?

I'm trying to work with the idea of the existing constructor function and a
possible shorthand. Another problem with almost any suggestion is how it
may interact with destructuring and expectations (with any additions of
"bind these").

I am highly suspect that any solution that is both ergonomic and concise
could pass.

What about making an explicit `constructor` function invalid in the case of
the shorthand syntax?

```js
class Point(x, y) {
   ...
}

// As shorthand for:
class Point {
  constructor(x, y){
this.x = x;
this.y = y;
  }
}
```

If this kind of syntax can't fly, that's fine, but I feel there isn't going
to be an ergonomic way to have a simple way to bind constructor arguments.
Although that makes things like super calls potentially awkward, we can
also assume that if you extend a class that it calls super in the generated
constructor. I'm not offended by a short hand as my last post, as the
transition is quite natural if you need a more complex use case:

```js
class Point(x, y) {
  toString() { ... }
}

// Oh no, now I have complex logic!
class Point {
  constructor(x, y) {
Object.assign(this, {x, y});
...
  }

  toString() { ... }
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal for faster this assignments in constructor functions

[dante federici]

Any reason we can't consider a scala-like constructor?

```js
class Point(x, y) {
  toString() {
return `(${this.x},${this.y})`
  }
}

console.log(`??? ${new Point(1, 2)}`); // ??? 1,2


Doesn't conflict with existing syntax, it's clear, and you can still
shorthand most data-classes or structs to just:
```
class MyData(some, props, here) {}
```

I imagine this as the syntax:
```
class Point(x, y) { // implicits x, y as first two args of constru
  constructor(a, b, c) {
this.z = a + b + c;
console.log(this.x, this.y, this.c); // values of: a, b, c
console.log(this.x === a, this.y === b); // true, true
  }
}
```

And de-sugared:
```
class Point {
  constructor(a, b, c) {
this.x = a;
this.y = b;
// rest of body
this.z = a + b + c;
  }
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add "???" Unimplemented

[dante federici]

Not a bad idea -- I agree that it really belongs here, but its value is
much higher in something like TypeScript, where you can keep the typing
signature but have a missing implementation.

On Sat, Mar 24, 2018 at 3:32 AM Isiah Meadows <isiahmead...@gmail.com>
wrote:

> I would suggest, if you have support in your editor, just making a
> `???` snippet expand to `throw new Error("unimplemented")`. I've been
> doing similar (mod the snippet) for a while, and it's worked pretty
> well.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Fri, Mar 23, 2018 at 11:16 AM, dante federici
> <c.dante.feder...@gmail.com> wrote:
> > Simple example (ts):
> > ```typescript
> > interface SearchFunc {
> > (source: string, subString: string): boolean;
> > }
> >
> > // Later
> > let mySearch: SearchFunc;
> > mySearch = function(source: string, subString: string) {  ??? }
> > ```
> >
> > Simple example (js):
> > ```js
> > class MyClass = {
> >   foo() { return "foo"; }
> >   bar() { return "bar"; }
> > }
> > class ExtendClass extends MyClass {
> > foo(){ ??? }
> > bar(){ return `extended bar`; }
> > }
> >
> > // Elsewhere
> > myRunner = (classInstance) => `${classInstance.foo()} ::
> > ${classInstance.bar()}`;
> >
> > myRunner(myClassInstance);
> > myRunner(extendedClassInstance);
> > ```
> >
> > Decorations would be good for classes, but don't work for regular
> methods.
> >
> > I'm not sold we need new syntax for this -- I just find myself reaching
> for
> > the `???` symbol. Especially in a typed language or in any instance that
> we
> > have a class and extended paradigm, or when you have a prescribed
> "object"
> > shape.
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add "???" Unimplemented

[dante federici]

Simple example (ts):
```typescript
interface SearchFunc {
(source: string, subString: string): boolean;
}

// Later
let mySearch: SearchFunc;
mySearch = function(source: string, subString: string) {  ??? }
```

Simple example (js):
```js
class MyClass = {
  foo() { return "foo"; }
  bar() { return "bar"; }
}
class ExtendClass extends MyClass {
foo(){ ??? }
bar(){ return `extended bar`; }
}

// Elsewhere
myRunner = (classInstance) => `${classInstance.foo()} ::
${classInstance.bar()}`;

myRunner(myClassInstance);
myRunner(extendedClassInstance);
```

Decorations would be good for classes, but don't work for regular methods.

I'm not sold we need new syntax for this -- I just find myself reaching for
the `???` symbol. Especially in a typed language or in any instance that we
have a class and extended paradigm, or when you have a prescribed "object"
shape.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Add "???" Unimplemented

[dante federici]

With the advent of TypeScript, classes, etc one feature I liked from scala
is: `???`, the [Predef.???](
https://www.scala-lang.org/api/current/scala/NotImplementedError.html)
token.

Basically, you can place `???` which would type as whatever the method is
typed as (for things like Typescript, Symbol definitions, etc.), and when
run, throws the "NotImplementedError".

This is useful when writing libraries or other code -- more readable that
"cannot call undefined" when the method is missing, and a nice placeholder
for young APIs.

This is basically the same as writing: `throw new Error('Unimplemented')`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Ideas on a testing focussed code transform

[dante federici]

To add to this --- a Monad is a useful concept for separating the
description of execution versus actually running the execution:
https://www.wikiwand.com/en/Monad_(functional_programming)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: import { foo, bar } as obj from 'module

[dante federici]

Definitely make a proposal for this -- I'm pretty tired of colliding
utility function names and having to aggressively namespace them.

It's been said but I want to just throw in another voice that this will
100% work with tree shaking, and as we get better at organizing our modules
and dependencies, it'll become more apparent.

With all the pushes toward pure functional code, utility modules and
libraries will benefit more and more from tree shaking and clear / strong
import/export syntax.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Definition mixins

[dante federici]

I'm having a little trouble parsing your proposed syntax. Can you formalize
it a bit better? Am I write in guessing that it's more like sugar around
bind and composition?

Like, what's going on here?

  mixin obj, mixinFunc1 as method1: privateState, privateStateObj;

I guess I'm wondering why this would be a part of the language and not just
helper functions and a library? Maybe it'd be helpful to represent your
chess example using your proposed syntax...?

Some questions (that may be moot once I actually understand your syntax):
* How does it actually prevent colliding names?
* How does it interact with closures?
* How does it prevent mixins from colliding over shared state?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Set.prototype.toggle

[dante federici]

I guess a better way to phrase my argument is:

What situation are you in where you don't know the current state?

That is, consider the following:


```
if (enabled) {
  set render state to "enabled", set action to "delete"
} else {
  set render state to "disabled", set action to "add"
}
```

versus:

```
set action to "toggle"
if (enabled) {
  set render state to "enabled"
} else {
  set render state to "disabled"
}
```

What I'm trying to say is that "toggle" is ambiguous without checking the
current state. Adding a set toggle method only serves to allow "drift" --
where you have a state assumption of "enabled" but the set is actually
disabled, or vice versa. Set should be explicit -- this doesn't mean you
need to litter your code with guards, but instead the state of an
application using a set should know if it needs to remove or add, and the
use of a "toggle" implies the state of the set is ambiguous. Either way. I
don't think the UI checkbox use case is compelling enough to add to the
prototype for Set.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Set.prototype.toggle

[dante federici]

What's the case for toggle other than nice to have? In general, I find
toggle actions to be implicitly dependent on existing state -- that is,
anywhere you have toggle you can just as easily say `add(value)` or
`delete(value)`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Array.prototype.mapOn method

[dante federici]

I'd be -1 on adding something like this to the language. This is better
solved with a library.

Transducers are a much better general solution than by stacking or adding
special array functions. You don't want to solve the "map with filter"
case, since there are many, many more combinations (take after map, filter
on map, group with map, etc.).

Some details on transducers:
https://clojure.org/reference/transducers
https://github.com/cognitect-labs/transducers-js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

Sorry I was unclear -- I was referring to "If we were to add this syntax,
then seeing this code with knowing how JS interprets the current syntax, I
would expect [x] to be the outcome"

I wasn't trying to imply it would work as-is -- either way, sorry for not
being clear. If anything the confusion around the newline interacting with
the shortened syntax as well as this miscommunication should probably
indicate something about the idea.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

The use case fading away doesn't mean you can drop support for it, or that
it won't still be in use.

Please stop trying to push your "shorthand" syntax of:
```
myFn() {
}
```

It's already been pointed out in multiple cases that:
1. The current usages are not "outmoded"
2. The proposed syntax has misleading `this` binding without the arrow
3. Blocks, ASI, and the object shorthand notation either conflict or make
it vague how to interpret

This isn't a beneficial syntax moving forward, and it doesn't seem to add
anything other than "I don't like typing '='".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Since we're discussing arrow functions and syntax...

[dante federici]

I'd check out the bind and pipe operators:
https://github.com/tc39/proposal-bind-operator
https://github.com/tc39/proposal-pipeline-operator

But my problems are `=>` and `->` would really lead to some sadness.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

Another annoying thing JS has to deal with is:
```
// implicitly 'var'
someVar = 10;
```

So, something like:
```
myFn() {
}
```

Would be considered as:
```
var myFn = function() {
}
```

with what semantics exist now. Not best practices, but what is currently
interpreted in the language.

I'd 100% agree that, as a shorthand, this is nice:
```
myFn() { }
const myFn = () => {}
```

Which is what I mean. But I'm not the full implementation of JavaScript.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Shorter syntax for arrow function assignment

[dante federici]

My major concern is this can be confusing with the "this" binding.
The object wrapping being the only difference between:
```
// Existing:
const x = {
  myFn() { }
};

// Proposed, with different meaning:
const myFn() { } // Why would "this" bind to myFn?
```
Omitting the arrow is a major -1 for me -- the whole point of "=>" is that
it does not provide a "this" to the scope of the function body.

Also, you cannot implicitly omit the "const", as these are all valid:
```
export var symbol = ...
export let symbol = ...
export const symbol = ...
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[dante federici]

I can totally feel the,
English break with,
Commas especially,
as a part of speech;
Semicolons do a great job of delineating sentences and statements;
But I have a special heart for separating bits from bytes.

I guess a return is a period?

Either way ---  I think my opinions are:
* end of statement style is a linting concern
* there's no benefit from comma optional
  => lint + fix can warn or make right in the exact get/set case
* ASI is... a stopgap
* srsly go to coffeescript or sugarjs if you want to type less (P.S. don't)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[dante federici]

I mean, it's the general case of the "get" and "set" when defining a method:
https://www.ecma-international.org/ecma-262/6.0/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation

That being said, there's a lot of "you just shouldn't do that" in
javascript. Looking at you, `undefined` not being a reserved word.

Syntax aside, a question that hasn't been sufficiently answered is what
value does this actually add other than "I don't want to type ,"? Arguments
for "easier to read code" I would absolutely disagree with, since it may be
easier for one person, but not another. Giving a "line break matters" is a
terrible answer, since that would break a ton of backwards compatibility.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[dante federici]

In terms of style, and in terms of version control, either of these are
fine:

```js
const obj = {
  x: 10
  y: 23
};
// or
const obj2 = {
  x: 10,
  y: 23,
};
```

The mixed case is the most obnoxious one:
```js
const bad = {
  x: 12,
  y: 7
}
```


However, as pointed out, there is ambiguity with:
```js
const obj = {
  get
  x: 10
  y
  z: 24
  get
  myMethod() {
  }
}
```

I just don't see optional comma in a collection as a useful feature for the
language -- "whitespace matters" always makes me uncomfortable, especially
since there are different standards for line breaks across machines
(looking at you `\r\n`), whereas the `,` token, which is already used to
delineate arguments, is suited exactly for this job.

The one thing I still have a gripe over is the class definition syntax --
where neither `,` or `;` are used at the end of method expressions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[dante federici]

I think the only place I see as a current inconsistency is with class
definitions vs object definitions. It probably should have been looped into
the object shorthand definition:

https://github.com/tc39/proposal-class-fields
```js
class MyClass {
  prop = 123
  constructor() {}
  method() {}
}
```
vs
```js
const myObj = {
  prop: 123,
  constructor(){},
  method(){},
};
```

Also, to wit on the class-fields proposal and this issue:
https://github.com/tc39/proposal-class-fields/issues/7
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[dante federici]

What benefit does this give the language?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Native Function Composition

[dante federici]

This is probably covered by the pipeline operator proposal:

https://github.com/tc39/proposal-pipeline-operator
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Strawman: `Function.prototype.try` (or `Function.try`)

[dante federici]

There exist lots of libraries that give this sort of functionality among
others in the functional community -- lots of Either or Maybe
implementations.

I don't think this is a healthy addition to the spec since you would then
want to consider all the other monadic goodies like mapping over these
values, folding, "all" and "some", etc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Defer expression

[dante federici]

kai zhu has a good example of solving async order problems explicitly, as
opposed to banking on any defer or timeout to figure it out.

I'm a little curious of what you mean by "something that cannot run
immediately".

If it can't be run immediately, then there should be *something* you can
hook into to run -- otherwise you're playing guesswork on what is currently
scheduled to execute.

Examples of the arbitrary use of "setTimeout" to defer to another script
frame in the DOM is when a frontend framework hasn't created elements yet,
and you need to run a query selector to grab them, or similar shenanigans.

I'd argue more that these are all anti patterns, since why should you be
guaranteed that toDoLater() can even be run after the setTimeout(1) or when
the Promise scheduler runs?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: A few module ideas

[dante federici]

   - Unable to load classic scripts (and other types of resources
   statically e.g. conditional modules) as part of the module graph

How are conditional imports static? In both examples I see the module as
being async, and therefore every dependent module is async. Your "dynamic
but static" is explicitly using "then" -- or are you implying a module
exporting async resources is a better solution than an async module?


   - Unable to specify more specific behavior for a module to prevent
   duplication

By passing arguments in, what do you expect to occur? Do you expect the
module itself to be run with those arguments, exporting a set of things?
How is that any better than just importing a constructor function from the
module/library? This problem sounds like designing the library in a better
way would make more sense than affording config to be passed into import,
which would mean each import would re-run the module, so no caching.


   - Either have to have lots of almost duplicate import declarations or
   have to load unnecessary files

I can see a benefit for reducing files in the static export -- that
suggestion has been a good example of existing problems with tree shaking
d3, to which the response has been "design better exports". As for the
multiple fetch part of the problem, HTTP/2 spec addresses the performance
hit for that, and it's effectively what you're asking the "static" prefix
to assert. Out of curiosity, how would you expect static to work in the
first place? Who would do the assertion that it doesn't depend on any other
symbol in the module it is a part of?

I feel like out of these, the solution is much closer to "Better library
design". I'm still not 100% on how your dynamic example addresses "turns my
code async".  Static export is an interesting one -- effectively asking for
pure symbols. Maybe identify an entire file as "load only these symbols,
ignore other source"?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: JavaScript Versioning

[Dante Federici]

A few times now you've proposed a "use _x_" syntax to achieve breaking
changes to the language.

"use strict" is more an attempt to condense the language and take a first
pass best practice. Not a means of "versioning" JS.

The bottom line here is that browsers aren't a place for a type safe and
correct language (well, thy could have been but hey, such is history).
They're a medium to consume information over the internet. Versioning would
be awesome and great, but there's always the "I don't want to leave X in
the dust" use case that needs to be considered.

"use strict" doesn't leave them high and dry, but does push the web to a
better place.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Add an easier method for slicing and stepping strings and arrays

[Dante Federici]

This feels like an attempt to get toward python's style of slice
. Which
I'm not opposed to, and would like to hear how it's better than just the
method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss