> that's basically the entirety of the syntax sugar proposals since ES2015,
right?
Definitely no, but talking about the syntax additions since ES2015, they
are in one or more of the categories below:
- avoid known footguns in the language (arrow functions and lexical this,
classes and prototype,
> ```js
> function stuff(source, extra) {
> const {value, method} = source;
>
> if (condition)
> method.call(source);
>
> if (value === extra)
> source.value = 'no more';
> }
> ```
I mean, in this case you can skip destructuring altogether, having a one
way and way only of value
I don't know, the by reference destructuring seems a bit too much magical,
a scoped variable that sets to a property to a object just sounds like the
old `with` statement but reduced and more explicit, given is just a sugar
and currently the problem is not a great of a pain point I would be very
We could wirte a simpler parser just for the imports subset, given the
simpler isolated grammar I don't think is that hard with parser
combinators. Maybe it's a cool idea for a npm library that just points out
the dependencies of a single file and then recursively scan the rest. From
that is just
Maybe a convention between hosts to prefix an import with an integrity
check?
``` js
import foo from 'sha1sum:ef70d15a0700d2108e0df27dde750f5c682b4697!./foo.js';
```
It looks kinda of dirty, but the specification allows it (aside from the
colon character that is forbidden right now)
This types of
The real risk are the exploits that are not made public
In my opinion __proto__ as a whole should be the one to be dropped,
unfortunately this is not happening in the near future. My hope is that one
day, years after now, the usage is so low that it can be removed from the
language. That would
If I understand it correctly, I had a similar problem with generated apis
from OpenApi, two apis have a error definition with the name ApiError, i
want to reexport all classes (a lot of model definitions) from both apis.
The problem is that using `export * from 'api-a'; export * from 'api-b';`
To me this is more a use case for using Set instead of arrays, the support
is already great and it can be polyfilled. Set is the right data structure
to verify if some element is or is not in a collection
Em sex., 7 de fev. de 2020 às 08:49, manuelbarzi
escreveu:
> just a proposal to provide
) {
},
};
return bar;
}());
```
Foo will never be resolved, because the awaited `bar` object never
calls the callback argument, and the whole block stagnates waiting for
something that will never happen
Em sex, 21 de jun de 2019 às 10:40, Augusto Moura
escreveu:
>
> The do expre
The do expressions proposal[1] had some discussions about having a
`async` variant[2] you should give it a look
Is the same concept you are proposing
[1]: https://github.com/tc39/proposal-do-expressions
[2]: https://github.com/tc39/proposal-do-expressions/issues/4
Em sex, 21 de jun de 2019 às
Fri, 14 jun 2019 - 18:29, Jordan Harband wrote:
>
> `nameof whatever` → `Object.keys({ whatever })[0]`, but I'm a bit confused
> why it'd be better to type `nameof foo` in code, rather than `'foo'` - if you
> change `foo` to `bar`, you have to change both of them anyways.
>
Exactly, if you
Can you list the benefits of having this operators? Maybe with example use cases
If I understand it correctly, the operator fits better in compiled
(and typed) languages, most of the use cases don't apply to dynamic
Javascript
The only legit use case I can think of is helping refactor tools to
Just bringing to the table the other side of the discussion (not
agreeing with all of them)...
IIRC the biggest problem with a pick syntax is the syntactic noise
encouraging convoluted code. Even now just with destructuring and
arrow functions code can get messy really quickly. Another argument is
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
> The proposal improves what is broken by not returning broken results relevant
> to decimal numbers. The proposal allows users to get and set any portion of a
> number using indexes of an array, which can then be converted back to a
> number.
This is not a problem at all, that's not a single
There is space for improvement in low level programming in Javascript,
sure isn't the main focus of the language, but I don't think
unobtrusive proposals should be a problem. There's a lot of C/C++
number apis that would be really useful in some use cases (I'm
thinking now in matrix operations,
It is the valid answer, subclassing is the reason behind the design choice
of Promise static members depending on `this`. If it was a good decision or
not is another topic. `Array.of` was designed in a different occasion and
static methods inheritance was not a subject at the time
Em dom, 3 de
The module system is not filesystem based, but URL based, that's a lot
of differences between the two, URLs are designed to be unique and be
storage/protocol agnostic in most networks. Others languages are
following similar paths, Go for example even allows you to import
entire github projects
I don't think string namespaced names are the right feature here
Namespaces are intended mainly to avoid conflicts with names when
sharing a global scope (like when using classpath in Java, or libs in
C++)
Javascript already solves this problems with modules, you can always
guard your code with
In the proposal:
> ``` js
> class SizedArray extends Array {
>
> constructor(...args) {
> if(args.length > size) throw new SyntaxError('Argument size is too big.')
> super(...args)
> }
> push(i) {
> if(this.length + 1 > size) throw new SyntaxError('Cannot push items
> anymore,
If you don't want the iterable features neither the own properties,
what're the benefits over a object indexed by numbers `const o =
Object.create(null); o[0] = 12; ...`?
About the other function proprosal (`Function.create`) I don't see any
benefits in day to day use having a function without
Extracted from the proposal [1]:
> Instead of waiting for the community to define and agree upon decorators for
> these purposes, why not define them now?
In my opinion this is not how things should be done, in my opinion we
actually should follow user-land patterns and help modifying/extending
I forgot the links in my last email, here they are:
[1] https://github.com/tc39/proposal-decorators
[2]
https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
escreveu:
>
> In the ~maybe long~ future , after the c
In the ~maybe long~ future , after the current decorators proposal
[1], we can start thinking about a Method Parameter Decorator (already
proposed [2]), we could do something like:
``` js
class Foo {
constructor(@field foo) {
}
}
```
In my opinion, it would be a much more powerful approach
Why would you destroy a node and `.then()` pause it? It doesn't make
sense even in plain English. If the contract of the method (expected
behavior) is to destroy the internal node, using it after is a error.
You can easily reimplement your use case reversing the logic:
js
setTimeout(() => {
24-08-2018 19:29, Aaron Gray :
>
> Yeah it does look like its badly "broken by design".
>
Why this behaviour is broken? Every OOP language that I worked with
behaves de same way, and there's not many developers complaining about
it. If you want to use a property that might be overrided in a
e
> }
> ```
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Fri, Jul 20, 2018 at 12:15 PM, Augusto Moura
> wrote:
> > I think what Jordan means, it's that the deferred has it use case, but
> > probably we don't w
sex, 20 de jul de 2018 às 15:57, Richard Gibson
escreveu:
> On Fri, Jul 20, 2018 at 12:15 PM Augusto Moura
> wrote:
>
>> Interesting enough, I got a really weird case (reads contraintuitive, I'm
>> pretty sure the semantics of the error are right) extending the Promise
future operators (`!on` or `!hasOwn`)
I don't see any problems with a `!in`. Legacy bad design should not affect
language consistency of new features.
Em qui, 19 de jul de 2018 às 12:07, Mike Samuel
escreveu:
> On Thu, Jul 19, 2018 at 10:40 AM Augusto Moura
> wrote:
>
>&g
t; - `capability.resolve(value)` - This invokes the implicit resolver
> >>> created for it, spec'd as [[Resolve]].
> >>> - `capability.reject(value)` - This invokes the implicit rejector
> >>> created for it, spec'd as [[Reject]].
> >>> - `capab
her or not the property exists
> without triggering a getter.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
*An errata in my code*
The getter is mutating the object with a enumerable property, so
consecutives invocations of JSON.stringify will result different from
the first call (if the property is yet not initialized). The current
problem is:
```js
JSON.stringify(foo) // Returns "{"bar":3}"
// After
On June 27, 2018 09:23, kai zhu wrote:
> what would happen if you tried to JSON.stringify foo? a core-value of
javascript to industry is as an idiot-proof/least-surprise language for
serializing json-data across browser <-> server. junior-programmers who
naively employ hard-to-serialize things
etime ago.
[1]: https://github.com/tc39/proposal-decorators
[2]: http://groovy-lang.org/metaprogramming.html#xform-Lazy
--
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
fined
>
> without the need to convert all the object keys into an array, but
> directly accessing one.
>
> Best,
> Serghei
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
etical keyword "promised" before the function
>> statement makes it act as a promise.
>>
>> Just a crazy idea I had. :)
>>
>> _______
>> 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
>
--
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
'Unimplemented')`.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.o
stions();
silent(() => showSuggestions(suggestions));
} catch (e) {
alert('Failed to load suggestions');
}
```
This isn't even a workaround, it's just the right approach for what you
want. If you wanna to evict the separated functions you can just inline the
try/catch in the main function.
--
See
https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md
for
clarification of the `#` sigil choice.
--
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ise((resolve) => {
interface.question(question, resolve); // You can wrap resolve in a
`unary` helper if more than 1 argument is problematic
});
```
I don't see a problem with verbosity
--
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
(() => {
console.log([123].indexOf()) // quack
})
console.log([123].indexOf()) // -1
```
Note, it will only work with sync code, async code (callbacks, promises)
will ~probably~ be called after the reset of the prototype function
--
Augusto Moura
___
How about `own` keyword? It might work with public and private fields, and
seems more elegant (because of destructuring we have a lot of symbols in
the paremeters declaration)
```.js
// This will throw a SyntaxError?
class Rectangle {
constructor(own #x, own #y, own name) {}
}
```
There's a
What would be the result for `Boolean.parseBoolean('undefined')` and
`Boolean.parseBoolean('null')`?
--
Augusto B. Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
counts for this as `::arr.push` with no expression before the
`::`.
Logan
On Tue, Mar 7, 2017 at 4:33 PM, Augusto Moura <augusto.borg...@gmail.com>
wrote:
Before I open any suggestion for my ideia in the [bind-operator](//
github.com/tc39/proposal-bind-operator) proposal, I like to know you guys'
o
Before I open any suggestion for my ideia in the [bind-operator](//
github.com/tc39/proposal-bind-operator) proposal, I like to know you guys'
opinion about, and if even it is in the scope of the current proposal.
There are moments when we want to export instances methods binded with
their
45 matches
Mail list logo
