On Sat, Mar 23, 2013 at 9:22 PM, denom <jim.feedb...@gmail.com> wrote:
>
>
> ------ Original Message ------
> From: "Rick Waldron" <waldron.r...@gmail.com>
> To: "denom" <jim.feedb...@gmail.com>
> Cc: "Axel Rauschmayer" <a...@rauschma.de>; "es-discuss list" <
> es-discuss@mozilla.org>
> Sent: 3/24/2013 12:54:43 AM
> Subject: Re: Upcoming talk on ES6 in Russia
>
>
>
> On Saturday, March 23, 2013, denom wrote:
>
>> Hello Dr. Rauschmayer,
>>
>> Could you plase explain how the slide #23."Object literals" comes in
>> alingment with slide #7."Challenges of evolving a web language" where it is
>> written "Preserve nature of JavaScript" ?
>>
>> The method definitions presenteed on #23 voided anything that
>> JavaScript Object Notation stands for which I consider it is indeed a basic
>> building block of JavaScript and no nature preserved here.
>>
>
> I suspect you may be conflating Object Literal syntax with JavaScript
> Object Notation specification—method definitions have never been part of
> the latter.
>
>
> I don't know in which version of Object Literal definition are you
> referring but mine goes like this; "An object literal is a list of zero
> or more *pairs of property names and associated values* of an object,
> enclosed in curly braces ({})."
> Source :
> https://developer.mozilla.org/en/docs/JavaScript/Guide/Values,_variables,_and_literals#Object_literals
> which
> I believe you specifically
>
Yes, thank you, but you said...
"The method definitions presenteed on #23 voided anything that JavaScript
Object Notation stands for"
And since "JavaScript Object Notation" does not include methods and Axel's
slide illustrates _an_ _object_, I'm left to assume you really meant object
literal syntax. Please don't cite URLs to non-normative, supplementary
content as some kind of evidence to an argument that fails to materialize.
> A mixture of named fucntions, voidance of key/value pairs, and
>> property values shorthand seems like a soup of a little bit of everything
>> and a soup was never a good friend of maintenability of the code. This is
>> monsterous.
>>
>
> The affordance of redundancy removal is actually really fantastic for
> maintainability ;)
>
> There is nothing that can be afforded here really. :) And how
> maintainability gets something out of it?
>
It was your claim that the shorthands were "never a good friend of
[maintainability]". I argue that code comprehension is improved when there
is less in the visible field; comprehension and readability directly inform
maintainability. Why you made the claim against maintainability in the
first place. Seems like this is less interesting then the next part...
>
> You are attempting to stuff so many things in an object literar that after
> writting few lines of code inside it you wont even realize that you are
> in an object literal. Hopefully only a trailing comma on the end of each
> line will make you suspect it.
>
> The worst is that the *Homogeneity* of JavaScript is cracking widely and
> that allows developers to split into dogmas between old and new
> specifications which will want to enforce on projects and is something to
> be expected. Jumping from one project to another will be like switching
> between different programming languages at some deegree. Everybody have
> seen this already with coffeescript (which is kinda cool) but moving to
> that direction and splitting the JavaScript developers further into
> groups/dogmas is just not affordable and I can not understand the
> difficulty some people face comprehending it.
>
I'll agree that this example:
let name = 'foo';
let obj = {
__proto__: SomeObject // special prop (1)
myMethod(arg1, arg2) { // method definition (2)
super.myMethod(arg1, arg2); // super reference (3)
},
[name]: 123, // computed property key (4)
bar // property value shorthand (5)
}
...is totally insane and I never would've written this for a slide to teach
people about these new syntactic forms... but computed properties (the
`[name]`) aren't final yet, so remove them from the equation and __proto__
is a lost cause.
// old
var obj = {
prop: prop,
method: function() {
....
}
};
// new
let obj = {
prop,
method() {
....
}
};
...This is much clearer to read and grok.
>
>
>
>
>
>> I see lots of drafts and proposals tend to be from people used to write
>> C(*)/Java or CoffeeScript
>>
>
> Can you cite a reference for this claim?
>
>
> A reference?? Here.
>
> Arrow functions (C# LINQ) : var squares = numbers.forEach(e => e*e );
> You can easily run the same code in C#.
>
> Destructing Assigment (CoffeeScript), here is a short tutorial
> http://blog.carbonfive.com/2011/09/28/destructuring-assignment-in-coffeescript/
>
> Ruby recently (v. 2.0.0) implemented default parameter values as well like
> this is proposed in here as well.
>
> Classes --> Need to say more?
>
What's wrong with allowing good syntactic or semantic design choices inform
and inspire?
> Now , reffering to the above doesn't mean I am against of everything. I am
> just making a point that influence from other languages is strong but
> JavaScript is already a well established language(and probably the most
> widely used) so no need to reinvent everything here and carry every legacy
> that some sets of contributors got by programming in other languages just
> because is more comfortable for them.
>
Improve the existing language and respect conventions,notations and syntax
> of the JavaScript.
>
> It will end up as a bastard chaotic set of something different than
> JavaScript that none will fully understand when, what and how to use.
>
> Finally I am really sorry that I had to writte all these in a mail that
> was not meant for this purpose.
>
Real technical arguments are welcome, but this is just more negativity and
I'm still failing to see what technical points (if any) you're trying to
make—beyond telling us all what we _should_ do... It reads like an airing
of grievance from atop a soapbox.
Rick
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
