Re: Pseudo headless arrows

2016-04-21 Thread Fabrício Matté 
@John: Good point.
IIRC, Mocha was (is?) one of such test frameworks that inspect the
function's `length` property in order to determine whether the author
intends the test to be run asynchronously (i.e. the first argument receives
a function that must be called when the test is done).
Whether that is a good practice is questionable, however.

/fm

On Thu, Apr 21, 2016 at 7:44 PM, John Lenz <concavel...@gmail.com> wrote:

> _=>{} is a function that takes one param and is not equivalent to ()=>{}.
> Some test frameworks inspect the function and care about the difference.
> On Apr 21, 2016 3:34 PM, "Fabrício Matté" <ultco...@gmail.com> wrote:
>
> The `==>` token would look like a new operator, which developers would
> have to look up in order to know exactly what it does. It is more confusing
> than helpful, IMHO.
> Also `==>x` has the same length as `_=>x`, the latter not introducing any
> new syntax (although it does employ an ugly unused identifier).
>
> By the way, this may be of interest to you: Headless Arrow Functions
> proposal <http://bterlson.github.io/headless-arrows/>.
>
> /fm
>
> On Thu, Apr 21, 2016 at 3:48 PM, Peter van der Zee <e...@qfox.nl> wrote:
>
>> 
>>
>> There are two ways of writing argument-less arrows;
>>
>> () => x;
>> _ => x;
>>
>> (Where `_` can be any identifier, of course.) I understand why we
>> can't drop the head entirely so if we're forced to type anything at
>> all, anyways, why not at least make it simpler by pressing two
>> different keys instead of three/four:
>>
>> ==> x;
>>
>> I don't believe this leads to syntactical problems anywhere, not even
>> with arrow functions themselves and it's future proof for at least the
>> cases I'm aware of.
>>
>> It's a minor addition but I think it's much nicer than either of the
>> two alternatives we currently have, which lead to a lot of
>> inconsistencies (it's spaces and tabs all over again).
>>
>> Semantics are the same otherwise as `() => x` would be.
>>
>> - peter
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pseudo headless arrows

2016-04-21 Thread Fabrício Matté 
The `==>` token would look like a new operator, which developers would have
to look up in order to know exactly what it does. It is more confusing than
helpful, IMHO.
Also `==>x` has the same length as `_=>x`, the latter not introducing any
new syntax (although it does employ an ugly unused identifier).

By the way, this may be of interest to you: Headless Arrow Functions
proposal .

/fm

On Thu, Apr 21, 2016 at 3:48 PM, Peter van der Zee  wrote:

> 
>
> There are two ways of writing argument-less arrows;
>
> () => x;
> _ => x;
>
> (Where `_` can be any identifier, of course.) I understand why we
> can't drop the head entirely so if we're forced to type anything at
> all, anyways, why not at least make it simpler by pressing two
> different keys instead of three/four:
>
> ==> x;
>
> I don't believe this leads to syntactical problems anywhere, not even
> with arrow functions themselves and it's future proof for at least the
> cases I'm aware of.
>
> It's a minor addition but I think it's much nicer than either of the
> two alternatives we currently have, which lead to a lot of
> inconsistencies (it's spaces and tabs all over again).
>
> Semantics are the same otherwise as `() => x` would be.
>
> - peter
> ___
> 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: [ small request - Javascript for javaing]

2016-01-01 Thread Fabrício Matté 
On Fri, Jan 1, 2016 at 3:47 PM, Herby Vojčík  wrote:

> Maybe we should rename the colloquial name of the language, to give clear
> signal to this kind of Javaist that Java should not have been there at
> first place and JS is something else. To retain .js extension it should be
> some J-word, like JumboScript, JiffyScript, JiveScript or something like
> that.
>

The "real" name of JavaScript is ECMAScript, which is in the name of the
list you are posting to.

JavaScript is a twenty years old trademark that has spread through the
whole web and became the most popular programming language name in the open
source world. It does not make any sense to change it now. Even if it did
make sense, the ECMAScript discussion list is not a place to discuss
trademarks and how the language is informally called—people may want to
call it WafflePickle, but that is not something you can standardize through
the ECMA process.

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

Re: Legitimate uses of IIFEs?

2015-12-20 Thread Fabrício Matté 
On Sun, Dec 20, 2015 at 8:39 PM, Bergi  wrote:

> I've never heard of an "Arrow function expression" - it's just "arrow
> function" :-)


It is true that the current spec. always refers to the production as
"ArrowFunction". Though, there are threads proposing Arrow Function
Definitions and Arrow Function Method Definitions, so I thought adding
"Expression" would be more future-proof. But indeed, there is currently no
such thing as Arrow Function Expression, so this may be more confusing than
not.

I think it would always be clear from the context anyway.
>

Having to scan through the context to figure out the meaning of a term adds
unnecessary cognitive overhead, and even then it is ambiguous in some
contexts.

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

Re: Legitimate uses of IIFEs?

2015-12-20 Thread Fabrício Matté 
On Sun, Dec 20, 2015 at 7:32 PM,  wrote:

> there is no reason to create an async function to invoke another async
> function; one can simply invoke it, and if the result/completion is
> required, use it's ,then() memberbut there's no need/advantage to
> wrapping such an invocation in an IIAFE, right?


I believe the advantage is that you can then replace the
`.then(onFulfilled, onRejected)` constructs with `await/try/catch`, thus
simplifying the code and improving readability. I recognize this may be an
uncommon pattern though, as most often the caller of an async function will
be an async function as well. Note that I say "uncommon" referring to async
IIFEs inside non-async functions; async IIFEs are still very useful to
parallelize sequences of async operations as I've mentioned before.

Btw, the term "IIAFE" should probably be avoided, as the "A" can
ambiguously mean "Arrow" or "Async".

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

Re: Legitimate uses of IIFEs?

2015-12-19 Thread Fabrício Matté 
You can use II(A)FE to summon strict mode in sloppy contexts (such as
Chrome's DevTools console):

```js
(() => {
  'use strict';
  // ...
})();
```

This is useful as Chrome either does not implement or uses legacy semantics
for quite a few ES2015 features in sloppy mode (e.g. let, const).

As for real code you would write, seeing as ECMAScript modules are
implicitly strict and we should have do-expressions soon, I don't see much
use for IIFEs anymore.

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

Re: Legitimate uses of IIFEs?

2015-12-19 Thread Fabrício Matté 
Good call, Dmitry. Async IIFEs are also useful to parallelize different
sequences of async operations. E.g.:

```js
async function main() {
  await* [
(async () => await seq1op2(await seq1op1()))(),
(async () => {
  await seq2op1();
  await seq2op2();
})(),
  ];
}
```

Here is a more solid example

.

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

Re: Legitimate uses of IIFEs?

2015-12-19 Thread Fabrício Matté 
@bread I see you are referencing Dmitry's sample, but why do you say it
won't work? AFAIK async functions return promises, so you don't necessarily
need a top-level `await`. I believe this (extremely ugly) sample should
work:

```js
function f(cb) {
  (async function() {
// await here
  })().then(v => cb(null, v), cb);
}
```

/fm

On Sat, Dec 19, 2015 at 7:11 PM,  wrote:

> That’s not going to work. The correct form still requires an (illegal)
> top-level await:
>
> await (async function() {
> // await here
> })();
>
> The easiest way to spawn a top-level async function is:
>
> here.then(function(result){},function(error){}) ;
>
> On 19 December 2015 20:14:44 -00:00, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>
>
> On Saturday, December 19, 2015, Šime Vidas  wrote:
>
> With block statements + let/const, IIFEs are no longer needed to emulate
> block-scoped variables. That got me thinking, are there other uses of
> IIFEs, or are they no longer needed?
> I’ve checked my code and found instances of this pattern:
>
> var foo = (function () {
> var a, b, c; // helper variables
> // some computation
> return /* final value of foo */;
> }());
> Btw, there is a "do expression" proposal (stage 0) [1] for this type of
> pattern.
> Anything else?
>
>
> FWIW, one of the still valid use cases is async IIFE, to spawn an async
> code (since there's no yet top-level async/await)
>
> (async function() {
>   // await here
> })();
>
> Dmitry
>
>
>
> ___
> 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: Legitimate uses of IIFEs?

2015-12-19 Thread Fabrício Matté 
On Sat, Dec 19, 2015 at 8:10 PM,  wrote:

> I believe await* has gone from the spec. The correct form would be (at the
> top-level):
>

True, I guess `await*` never made it to the proposal's formal text. It
still worked in Babel the last time I checked, though. FWIW, `await* []`
would desugar to `await Promise.all([])`.


> The mistake in Dimitry's example is that the async body was not resolved,
> not that anonymous async functions are in some way invalid - they're just
> fine.
>

I'm not sure if I understand what you mean. I see that the outer
synchronous function would not await until the async function finished—i.e.
the outer function would return before the promise was resolved/settled—,
but that is still valid syntax—you could be running the async code for
side-effects that the caller context does not need to be aware of. You
mentioned this was invalid syntax, and that was the initial point I
addressed. :)

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

Re: Exponentiation operator precedence

2015-08-27 Thread Fabrício Matté 
You don't need to be a language guru to know which operation will be
performed first, you can (and should) check an operator precedence and
associativity table such as MDN's
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
.
Knowing operator precedence and associativity is very important when
reading code written by others, and many projects use the no unnecessary
parens linting rule.

/fm

On Thu, Aug 27, 2015 at 8:35 AM, Bill Frantz fra...@pwpconsult.com wrote:

 On 8/27/15 at 11:51 PM, niloy.monda...@gmail.com (Niloy Mondal) wrote:

 x ** y ** z is easier to read/write than x.pow(y.pow(z))


 As a language guru, you know which operation will be performed first. As
 Joe programmer, I don't and I would need to write it as x ** (y ** z).

 With some operations, like +, the order doesn't matter and x + y + z is
 not confusing.

 Cheers - Bill

 ---
 Bill Frantz|We used to quip that password is the most common
 408-356-8506   | password. Now it's 'password1.' Who said users
 haven't
 www.pwpconsult.com | learned anything about security? -- Bruce Schneier


 ___
 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: Static local variables

2015-08-10 Thread Fabrício Matté 
What you've described seems very similar to PHP's static variables
http://php.net/manual/en/language.variables.scope.php#language.variables.scope.static.
They are very nice syntactic sugar, in my opinion.
I'm just not sure if this is worth adding new syntax to the language, as
there is already a pretty standard approach:

```js
var tmp;
function intersect_vector() {
tmp = tmp || new Vector();
// ...
}
```

Or with CoffeeScript:

```cs
tmp = null;
intersect_vector = -
tmp ?= new Vector();
# ...
```

Though, static variables would remove this boilerplate and make it easier
to reason about a given binding's scope. I believe they would be a nice
addition to the language.

/fm

On Mon, Aug 10, 2015 at 1:16 PM, joe joe...@gmail.com wrote:

 I've been hesitant to bring up this idea, because even though I use it
 extensively as a language extension in my transpiler I'm not sure it is
 normatively correct.

 When I started my first major JS project four or five years ago, I noticed
 I was doing this a lot:

 var intersect_vector_tmp = new Vector();

 function intersect_vector(v1, v2) {
 var tmp = intersect_vector_tmp .load(v1).sub(v2);
 //do something
 v1.add(tmp);
 }

 Basically, I was doing the following transform:

 *  For each static local variable...
 1. Build unique name from hash of lexical scope chain
 2. Rename variable (along with references to it in the local hoisted
 scope).
 3. Move it to module/global namespace.

 I ended up implemented this in my compiler as a sort of C-style static
 local variable.  Thus, the example above became:

 function intersect_vector(v1, v2) {

 static tmp = new Vector();

 tmp.load(v1).sub(v2);
 //do something
 v1.add(tmp);
 }

 There are, obviously, a great many problems here, starting with the fact
 that the variable's initializers are being evaluated outside of the scope
 they were declared in.  Unfortunately this pattern can be hard to avoid for
 high-performance code, so much so that if the transformation is done by
 hand you end up with a great deal of clutter.  This is especially annoying
 when dealing with classes, as the following file (with the statics
 transpiled out) illustrates:


 https://github.com/joeedh/fairmotion/blob/master/examples/vectormath_static_illustration.js

 This becomes a real pain after a while.  At one point I tried using shared
 object pools, but found that this didn't remove very much clutter because,
 in practice, each function had to have its own pool (usually one for each
 type of temporary object it uses).  This really does boil down to a lack of
 support for local stack allocation of temporary objects.

 Anyway, I just thought I'd put this out there. Who knows, maybe someone
 will invent perfect escape analysis for temporary const objects, and we
 won't need hackish language extensions such as this.

 What do people think? Too many normative problems?

 Best,
 Joe

 ___
 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: Module import/export bindings

2015-03-15 Thread Fabrício Matté 
Regarding the internal server error, see
https://github.com/esdiscuss/esdiscuss.org/issues/83#issuecomment-59661326

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

Re: A Declarative replacement for toMethod

2015-02-23 Thread Fabrício Matté 
```
PostfixExpression :
[...]
MixinExpression [no LineTerminator here] ++
MixinExpression [no LineTerminator here] --
```

Is this a typo? What is the point of the `++`/`--` postfix operators after
a `MixinExpression`?

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

Re: A Declarative replacement for toMethod

2015-02-23 Thread Fabrício Matté 
 It's establishing the precedence of the MixinExpression between
PostfixExpression and LeftHandSideExpression.

Thanks Kevin, I thought it could be the case, but I still can't see when
that is relevant -- as far as I can see, the resulting value of a
mixinExpression is always an object (or a constructor object), and those
would be invalid LHS expressions in regard to the `++`/`--` postfix
operations. I assume that BNF grammar is only necessary to establish the
precedence order for expressions that will ultimately throw an error, no? I
feel I'm missing something.

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

Re: Rev32 ES6 draft now available

2015-02-02 Thread Fabrício Matté 
So much awesomeness in this revision, congratz TC39!

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

Re: es-discuss Digest, Vol 95, Issue 45

2015-01-20 Thread Fabrício Matté 

 Point 2 is incorrect (e.g. `new (Foo.bind.apply(Foo,
 [undefined].concat(args)))`).


I stand corrected. That's very good news, thanks!
Nice and elegant solution, by the way.

I should have taken the time to look at how current transpilers handle
that. Your solution is similar to Traceur's generated output, but it is
also interesting to see how [6to5 spreads arguments in a NewExpression](
http://6to5.org/repl/#?experimental=trueplayground=trueevaluate=trueloose=falsecode=class%20Foo%20%7B%7D%0Avar%20arr%20%3D%20%5B%5D%3B%0Anew%20Foo(...arr)%3B
).

Oh, I also had a typo in the previous mail (`s/rest parameters/spread`),
guess I was a bit too sleepy last night.

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

Re: Array.prototype.contains solutions

2015-01-20 Thread Fabrício Matté 
I faintly remember seeing a sort of proposal containing many different
approaches as how to solve this generic built-ins extensions problem in
future editions of ECMAScript.
I believe it was authored by Domenic Denicola, in Gist/GitHub format if
memory serves me right.

I can't seem to find it, does anyone have a link?
Or is memory tricking me and this thread was the end point for this topic?
Thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains solutions

2015-01-20 Thread Fabrício Matté 


 https://www.google.com/search?q=site%3Aesdiscuss.org+Array.prototype.contains+solutions
 leads to https://esdiscuss.org/topic/array-prototype-contains-solutions
 which is probably what you were thinking of.

 They were not very good ideas.


For some reason I thought you had evolved those ideas further after that
post, but if you don't recall it then my memory was wrong. Thanks for the
quick answer.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Fwd: es-discuss Digest, Vol 95, Issue 45

2015-01-19 Thread Fabrício Matté 

 In that case, we can expect that users will want to implement factory
 when called as a default behavior for their classes.  From that, we can
 foresee that the following pattern:

 if (!new.target) return new Whatever(...args);

 will become a kind of boilerplate.  Obviously, we want to avoid
 boilerplate as a general rule.


+1!

I personally consider `new` as user code pollution.
I have been considering to use classes but export factories in my libraries
and packages' code. The initial idea was:

```js
class Foo {/*...*/}

module.exports = function(...args) {
return new Foo(...args);
};
```

But the sample above has obvious problems:

1. It becomes a tedious boilerplate to wrap every single class into a
function export;
2. It can't be transpiled to ES5. Rest parameters are transpiled to
`.apply()` which can only do [[Call]] and not [[Construct]].

(forgot to CC es-discuss before oops, let's see if this forward goes
correctly now)

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

Re: es-discuss Digest, Vol 95, Issue 45

2015-01-19 Thread Fabrício Matté 
Your second example may break if the constructor is called via
`.call()`/`.apply()` or as a *CallExpression : MemberExpression* or if it
has been `.bind()`ed. Although these may look like corner cases, a good
transform should cover these cases, especially *CallExpression :
MemberExpression* as it is very common in Node.js land to have constructors
exported as properties of an exported object.

Btw, you're also missing a `return` before `this` in your global function
body.

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

Re: A new ES6 draft is available

2015-01-17 Thread Fabrício Matté 
I agree with Frankie. Assume a developer who has never seen this
`new.target` construct before.
They will first think that this is an invalid expression, as `new` is an
operator. Then, upon seeing this code execute, the natural question is
What is `new`? Is it an identifier injected into Environment Records
created by [[Call]] and [[Construct]]? Does this identifier resolve to an
object (so that the MemberExpression would make sense)?]

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

Re: A new ES6 draft is available

2015-01-17 Thread Fabrício Matté 
For a short term solution, I would suggest `arguments.new.target`.
The `arguments` object already contains info about how the function was
called (its arguments, the deprecated/obsolete `callee` and
obsolete/never-spec'd `caller` properties), so adding information about how
the function was called (whether it was `new`'ed) to `arguments` would make
sense imo.

For the long term, I'd like to see a new identifier injected into function
scopes which exposes the Lexical Environment/Environment Record internals.
Then we can use `__scope__.new.target` or `Reflect.isNewed(__scope__)` (or
`isConstructed`, which may make more sense seeing as there will be
`Reflect.construct`).
Of course, this `__scope__` binding should only be injected in the
Environment Record if the binding does not exist yet after registering the
function body's declarations, for back-compat reasons.
And obviously, `__scope` is just a placeholder name for this suggestion, I
don't really mind how it will be called.

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

Re: A new ES6 draft is available

2015-01-17 Thread Fabrício Matté 
 Currently in ES6, the only reserved keywords that can appear immediately
before a `.` are `this` and `super`.

The `this` binding resolves to a value, so MemberExpressions make sense.
The `super` keyword is being implemented in ES6, so there are no precedents
to set expectations.

 Any other reserved word followed by a `.` is a syntax error.  So reserved
words followed by period and an identifier is  one of the few available
extension alternatives we have available.  And is a natural ready syntax
think of new.target' as meaning give me the target value of the currently
active `new` operator.

I agree `new.target` is very natural and pleasant to read. It just feels
rather alien to see an operator in the beginning of a MemberExpression,
which currently would only be allowed in this very specific scenario. Of
course, if this syntax extension form would be useful for other use cases
as Kevin and you have outlined, then I don't oppose it.

 I suspect the hypothetical naive JS programmer postulated above wound't
be aware of any of those concepts.

A naive one probably not, but a curious avid developer most definitely
would. ;)

 hopefully they will say what is `new.target', google it and immediately
find the answer.

You mean, land on a Stack Overflow answer with thousands of upvotes and
very little explanation about why/how a MemberExpression can begin with an
operator. Of course, if you interpret `new` as simply a ReservedWord token
instead of an operator, then everything makes perfect sense.

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

Re: A new ES6 draft is available

2015-01-17 Thread Fabrício Matté 
Oh thanks! I just got a copy of the draft rev 31 to check it out.

Meta properties sounds like a good name to me. Also, JavaScript meta
properties does not have significantly relevant search results, so it
should be easy to google for in the future.

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

Re: Promise rejections don't resolve the argument

2014-12-28 Thread Fabrício Matté 
`Promise.resolve` and the Promise executor function's `resolve` argument
lets you delegate the fulfillment of the given promise to another promise
object. That is essential for composability.

In the other hand, `Promise.reject` and the Promise executor function's
`reject` argument are to be called at the point when the given operation
fails and you already have enough info to reject it with a `reason` (that
is, `reject` is similar to a `throw` when compared to non-async code). In
this context, it wouldn't make much sense to delegate the failing of a
promise, since reject is always called when you're 100% positive that the
operation has already failed. Just like `throw`, you can pass any object as
the `reason` argument to `reject()`, but good practices tell you to only
pass error objects.

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

Re: Promise rejections don't resolve the argument

2014-12-28 Thread Fabrício Matté 
*By any object I mean any value.
Anyway, it would be interesting to see a real use case for passing a
promise as reject reason.

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

Re: Promise rejections don't resolve the argument

2014-12-28 Thread Fabrício Matté 
Yes, delegating to another promise which then rejects should cover that use
case. `=]`

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

Re: Weak{Map,Set}.p.clear() implementation proposal

2014-10-28 Thread Fabrício Matté 
Nice idea, but there seems to be (some) complications.

 Set **this** to *T*.

What is `this` specifically? As far as I can see, it is a value and not a
reference. And even if it were a reference, setting it to point to another
object does not affect the other references which point to the old WeakSet.

On Tue, Oct 28, 2014 at 11:48 PM, Isiah Meadows impinb...@gmail.com wrote:

 I'm proposing simply initializing a new instance and GC'ing the old
 instance entirely (updating the `this` to point to the new) instead of
 the current algorithm of maintaining a list of keys. I know that it
 potentially slow down the method itself, but it could eliminate the
 need for keeping a Map-like index of keys.

 I know that this is kinda on the late side for such drastic internal
 spec changes, but might fix the problem of indexing WeakMap and
 WeakSet entries

 Link to formal proposal:
 https://github.com/impinball/weakmap-weakset-clear
 ___
 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

Fwd: Weak{Map,Set}.p.clear() implementation proposal

2014-10-28 Thread Fabrício Matté 
What I mean is, consider this code:

```js
var wsRef = new WeakSet();
var wsRef2 = wsRef;
wsRef.clear();
```

As far as I can see, in the `wsRef.clear()` algorithm, the `this` value has
no relation with the `wsRef` identifier. Even if there was some internal
magic around changing the identifier's reference, there would still be
other references pointing to the old WeakSet object. So your proposal seems
to require replacing an object in the memory with another while keeping the
references intact, which (I believe) does not exist in ECMAScript.

I may be wrong though, let's other for someone with more experience to have
a say on this. `=]`
​
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak{Map,Set}.p.clear() implementation proposal

2014-10-28 Thread Fabrício Matté 
​ Not in pure ECMAScript being interpreted, but it can definitely be done
in the implementation.

Yeah I think so too, but if no where else in the specification uses this
pattern, implementations would be required to implement new mechanisms and
possibly have de-optimizations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak{Map,Set}.p.clear() implementation proposal

2014-10-28 Thread Fabrício Matté 
I understand that objects are passed by reference in Java (similarly to
ECMAScript), however I'm not sure how implementations link Lexical
Environments' identifiers to their respective values, and re-mapping these
would be more complicated than the C++ sample you've posted I believe.​

As far as I can see, this seems a lot more complicated than it is worth,
and it would at least require a new abstract operation for internally
in-place replacing objects while keeping references intact.

Wouldn't it be far easier to just have an internal data property in each
Weak(Map|Set) which can be replaced by a new list/object? Then
implementations can just access/pass-by-reference the Weak(Set|Map) object
and methods can read its data property. In fact, that seems to be what the
spec already does:

 ### [23.3.3.1 WeakMap.prototype.clear ( )](
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.clear
)
 ...
 5. Set the value of M’s [[WeakMapData]] internal slot to a new empty List.

And

 ### [23.4.3.2 WeakSet.prototype.clear ( )](
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakset.prototype.clear
)
 ...
 5. Set the value of S’s [[WeakSetData]] internal slot to a new empty List.

How would your proposal simplify those algorithms?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.values is not web compat (even with unscopables)

2014-10-19 Thread Fabrício Matté 
@Benjamin

Not sure if I understand what you mean.

If standards don't dictate, then how are we supposed to expect
interoperable implementations?

By impossible I suspect you mean something that browser vendors should
never do. I understand back-compatibility with the Web is a must for
browser vendors, and that is good for us developers, too. After all, that
is what One JS is all about.

However, it does not take a fortune teller to take minimal precautions,
such as not walking up an (extendable) prototype chain when checking for
property existence in objects. I believe future ECMAScript versions have
the right to extend built-in prototypes, and developers must be aware of
that. This, however, may not be web-compatible, as it breaks code that
contains the aforementioned code smell.

Can the TC39 and browser vendors solve this in a reasonable manner?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.values is not web compat (even with unscopables)

2014-10-18 Thread Fabrício Matté 
Here is a related Twitter discussion:
https://twitter.com/domenic/status/523202298466418688

To highlight the main points:

 Domenic Denicola claims that extending built-in prototypes is not
web-compatible.

Indeed, if we consider all possible corner-cases and ignore best practices
(which is often the case for the Web), adding new prototype properties or
global identifiers can break existing code.

However, it is basic knowledge that 3rd-party code and future ECMAScript
versions can and will extend the built-in prototypes, and host environments
can inject new global identifiers. If developers do not keep this in mind,
they are writing what I call code waiting to be broken.

Developers already have the means to write future-proof code. For instance,
I believe Outlook's code could be made future-proof by simply using
`.hasOwnProperty()` instead of the `in` operator.

IMO, developers should be more mindful about future-proofness, and new
developers should be educated in this vein. This must happen in order for
ECMAScript to keep evolving without revolving around ugly/unnecessary
syntax such as pragmas and core library imports. Code waiting to be
broken should be of no concern to TC39.

But in reality, many developers simply won't follow the best practices, and
as Domenic said, browser vendors don't want to ship changes that break
existing code.

Looks like we have reached a stalemate, and I believe this is something
that should be addressed before ES6 is officially publicized.

O.T.: although I've been accompanying ES Discuss for a good while, this is
my first post here and I'd like to thank all TC39 members and contributors
for the awesome work so far.

/FM


On Fri, Oct 17, 2014 at 7:44 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:

 Here is some more info.


 http://windowssystemspecialist.blogspot.com/2014/10/fixing-blank-calendar-with-chrome-38.html

 (This blog post would have been useful when we tracked down what caused
 OWA to fail.)

 On Fri, Oct 17, 2014 at 5:13 PM, Jeff Walden jwalden...@mit.edu wrote:

 On 10/17/2014 01:53 PM, Erik Arvidsson wrote:
  [1] Microsoft Outlook Calendar web app (part of Exchange Outlook Web
 Access)

 Microsoft could ship a fix in a point release, right?  They surely
 already provide security patches that admins must install anyway, if they
 want to keep their users (and their data) safe.  If the fix is small, is
 there any reason why it couldn't be part of such a patch?

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




 --
 erik

 ___
 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