Re: ... A community is writing the spec...

Thu, 11 Sep 2014 05:59:04 -0700

 
> You can inject the proto but that's not really subclassing ...
 
You know, I'm starting to think that injecting proto is actually the right way to do subclassing. It preserves [[Class]], it doesn't depend on `new`, etc.
 
Here is some code I checked with: https://gist.github.com/rlidwka/0ad094386f60f93318bf
 
 
> If you bind the callback ask yourself why is that
 
Because not every function in _javascript_ supports passing contexts, so you have to bind stuff anyway for other functions. So it makes sense to bind everything for consistency reasons.
 
Also it's more convenient to have bound function as one variable that you can pass everywhere.
 
 
11.09.2014, 12:17, "Andrea Giammarchi" <andrea.giammar...@gmail.com>:
nope, looks like you forgot (sad) parenthesis :P
 
My point was that Array extras have this second argument there to pass a context and fat arrow, as opposite of the thin one, would make that parameter misleading/confusing/pointless (same as bind would but fat makes it easier to mistake the intent)
 
You know I wish thin arrow would have made it in ES6 as just exactly a function shortcut as we know it since ever, "nothing to spec" if not its -> syntax, much more use cases covered for all tastes.
 
Now I think we should (I will) leave this thread which intent is at this point unclear :-)
 
Alex ... you can't really subclass Arrays without redefining slice, splice, concat, and others behavior ending up loosing your initial "type" and I've been writing sublcassing tricks since 2008 
 
You can inject the proto but that's not really subclassing ... about tuning performance, it's not just that, it's convenient to pass dictionaries, maps, or parameters in there without binding because binding is indeed not needed since the second argument is the context as specs say.
 
If you bind the callback ask yourself why is that ... you probably chose to use half of the potential of the Array method for no reason.
 
Best Regards
 

On Thu, Sep 11, 2014 at 1:43 AM, Rick Waldron <waldron.r...@gmail.com> wrote:


On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> wrote:
with all due respect Rick, and you know we've been talking about this already, your forEach => example assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world 'cause basically impossible before ES6.
 
An implementation detail, don't nitpick.
 
  // Call a method of this object or class or whatever to make Andrea happy with my example
  var happies = sads.map(sad => this.makeAndreaHappy(sad));
 
 
That work for you?
 
 
 
Everybody else that used to pass a different context to do something more meaningful would fall in that trap at least once.
 
Of course they will learn "their" mistakes ... but please don't use forEach as example about how cool is fat arrow 'cause in my opinion, with Array extras, that's actually a perfect place where fat arrows is the most confusing.
 
Regards

On Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron <waldron.r...@gmail.com> wrote:


On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut <alexandre.morg...@4d.com> wrote:

Hi,

 
The way this discussion started looked very troll oriented, but let comment few things I more or less agree or not with 
 
 
 
What I see is more functionality of the browser api then an actually language.
 
I actually work for 4D that provide _javascript_ on the server in its Wakanda Server which is not using node.js (at least for now)
I have to disagree with this statement as I see very good added value in ES6 for our developers on server-side
 
 
 
 
And I look into node promise and the spec promise on MDN... And I'm still not seeing the big picture. Could you give me a brief in your own words....
 
I think the first place I saw Promise as a specification for _javascript_ was on the CommonJS mailing list and wiki
 
Then on WHATWG, first called Future (not anymore online) and via this github repository
 
Then in W3C drafts
 
Before finally going into JS core, then in ECMAScript
 
An interesting blog post about Promise history in JS:
 
It intends to make life better when chaining async callback calls which is absolutely not browser specific
It may have stay as a library, but then no Specification call rely on it, and many actually upcoming HTML5 features choose to rely on it
 
 
 

 
And this stupid ()=>{} arrow function... After seeing this I got the ideal of letting functions follow the same rules as for, if, while... That if it's one line of code, than let it be: 
function add(arg0) console.log(arg++);
 
With out a body --curly braces--... Funny thing is that Firefox allow this syntax style.
 
var arr = [];
[0,1,2,3].forEach(function(arg0)arr.push(100+arg0));
arr;
 
Copy & paste in Firefox to see.
 
I'm not big fan neither of fat arrow functions because:
- the code looks less expressive to me, code becomes very cryptic for anyone that don't know them and confusing as potentially associated to "+=",  "*=", ... 
 
There is nothing ambiguous about `=>` with regard to existing compound assignment operators. 
 
- they have no room for a function name that would be useful in debugger stacks and closure scope names, or profilers function call counts
 
Still beware those are not only about syntax but also have different behaviors. The binding of "this" is different
I admit I fear more confusion when I see people choosing the Array forEach() to show an example
By default "this" in the forEach callback is bound to its second parameter, so some developers may have some surprises
 
No, the default `this` in forEach is undefined. An explicit `thisArg` can be provided as a second arg. In the most common case, fat arrow simplifies.
 
  items.forEach(function(item, i) {
    this[i] = doSomeComputingOnItem(item);
  }, this); 
 
  // with or without the braces, it doesn't matter.
  items.forEach((item, i) =>  {
    this[i] = doSomeComputingOnItem(item);
  });
 
 
Any attempt to do: 
 
  // with or without the braces, it doesn't matter.
  items.forEach((item, i) =>  {
    this[i] = doSomeComputingOnItem(item);
  }, this);
 
 
Will just work because it means the same thing (even though the explicit `thisArg` is just ignored).
 
But mistakes like the following will be discovered very quickly and it's a mistake developers will likely only make once (if ever). 
 
  // with or without the braces, it doesn't matter.
  items.forEach((item, i) =>  {
    this[i] = doSomeComputingOnItem(item);
  }, someOtherObject);
 
 
 
 
 

And the generator function... Couldn't it have been: generator(args){
yield args += "gen"; 
console.log(args);
}
 
Plus with a constructor:
new Generator();
 
This is a little different story
Using non reserved keywords will for sure break some existing code
But of course another more explicit option could have been to provide a new method on the Function native object
ex: Function.generator()
 
What exactly does that do? If it's just a regular function, then how could `yield` have been safely made into a keyword within the body?
 
 
Rick
_______________________________________________
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

Reply via email to