I am on mobile so it's short one ... subclassing does not need new syntax, it needs eventually a fix on Object.create or a similar method. However, subclassing will always suffer cross frame issues, isn't it so how a triangle can magically solve this specific problems is a mystery to me but I'll be happy to show examples you can reuse to simulate new syntax features :-)
On Tuesday, October 4, 2011, David Bruant <[email protected]> wrote: > Le 04/10/2011 17:03, Andrea Giammarchi a écrit : > > David, as I have tweeted before, syntax is a non problem, surely is not a problem *now* because you already have alternatives such CoffeeScript, GWT, Traceeur or any sort of transpiler you want ... do all these new syntax bring real benefits to JavaScript ? > > I sent a message here explaining the necessity of a syntax construct for a reliable bind [1]. There is a need to investingate (one reply was very close from a solution) to make sure that such a thing is not possible in pure ES5 (without making Function.prototype.bind non-configurable), but that would be one such thing that no language compiling to JavaScript could emulate (since impossible in the language itself). > > The prototype operator allows subclassing which was a long awaited feature and this is not doable in pure ES5 (without __proto__ which IE has never supported). This doesn't require syntax, but the idea of the proto operator looks elegant to me (the idea, not necessarily the proposed syntax) > > Having new syntax for modules is not necessary per se but would be great to programatically analyse the module itself. > > But I agree that most other things may not be necessary for the language itself since they could be emulated in another non-syntaxy way (but I'd be interested in seeing the non-syntax equivalent to make sure syntax is not that helpful). > > I am not sure, I never needed new syntax, and all I know is that what's needed now cannot be obtained via transpiler > > Subclassing cannot be achieved (or requires to extend built-in which in some cases may not be what people want) since it's not possible in JavaScript itself. > > > at least not the performances problem you may face one day when things become a bit more complex ( just think about games ) > > A transpiler, CoffeeScript like stuff, can bring you already a simulation of block scope without problems and Mozilla is already working on Firefox tools able to debug CoffeeScript directly, rather than it's equivalent in JavaScript. > > But it's a tool. Mozilla doesn't work on a CoffeeScript emulator. It keeps investing (as everyone) in making a JavaScript interpretor. And such an interpretor would benefit from language constructs which offers invariants since invariants often result in performance improvements. > After his JSConf.eu talk on Garbage Collection, I discussed with Erik Corry who told me that strict mode helped a bit with performance (things related to scopes and eval). I would expect the same things from syntax operators: offering invariants which can help out with performance. > As long as JavaScript is the only thing that web browsers natively understand, we need to improve the language itself, syntax included since it's the only element of the language that programmers can't replace. > > This achievement is possible today, what's truly needed for performances, common patterns as String#format and all other things that could help us in shorter therms is not. > Last, but not least, I asked Brendan a question, and I better reasoned it in my blog. > I have not showed any community petition about this topic, but unless you learned JavaScript this year I do believe there are so many things you need that syntax, if you got, cannot have same priority ... am I wrong ? > > I agree with you, but syntax is one other problem as well. > > I agree with you it's not one voice, I don't agree when you talk about syntax changes in other programming languages because 100% of them are *not* in the web, at least not in users browsers. > If a language is on the server side nobody cares much about these syntax changes because they can chose the version they want. > > This is extremely true and this is the reason why ES.next will have an opt-in. > > As you mention, JavaScript has the particularity of being the only "mobile code on the web" language. Any change to the language will require an opt-in. As I said above, there are a couple of things that need a syntax construct, so I think that changing the syntax is necessary, and consequently so is adding an opt-in. > Since any syntax change requires an opt-in, I think we can agree that as many as many syntax changes as possible (and as necessary of course) should ship with ES.next (10 years from now, I don't want to see thousands of opt-ins) > > As a side note, an opt-in is not necessary for each syntax change. ES5 brought getter and setter initialization syntax. There is no opt-in. The downside being that no one can use them until IE8 is dead. (I agree that no one really care of this one, but you get the point) > > There are still services entirely based on PHP4, do they care about PHP 5.3 or 6 ? They will when necessary, when they can update their code. > Python 3000 has still poor support ... and even if server side only, you need a valid reason to choose Python 3 over 2.X because 80% of libraries out there are in Python 2 and these break in Python 3 > JavaScript is the exception that confirms the rule about programming languages since is unique option for everybody. > We have done so well until now updating and enreaching it that we should understand that non breaking features are most likely the best way to go and the transition between JavaScript and SomethingDifferentOutOfES6 should be as smooth as possible, and possibly focused on what's truly needed *now* - not the syntax, not today, please. > > When then? :-) > It seems that there will always be something that we need to do that may not require syntax. But modules, for instance is something we need now as well. Subclassing has been long awaited too. And for both, providing syntax constructs sounds relevant. > > David > > [1] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016395.html > > > On Tue, Oct 4, 2011 at 3:16 PM, David Bruant <[email protected]> wrote: >> >> Le 03/10/2011 22:49, Andrea Giammarchi a écrit : >>> >>> Dear All, >>> while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post: >>> >>> http://webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html < http://webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html > >>> >>> I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with. >> >> I have seen the sentence "I got 99 problems and JavaScript syntax ain't one" on twitter (by @mikeal), reused in Brendan's slide of CapitolJS and at JSConf.eu. >> Plenty of people seem to agree with this and I would like to take one minute to justify why syntax is important in my opinion. >> >> Currently, I can cite only one IDE that has decent JavaScript support: WebStorm. And they have a very good completion suggestion engine. I have seen JavaScript IDEs stopping to analyse when coming across the (function(){...})(); pattern. >> >> Why aren't there that many good JavaScript IDEs? Because JavaScript is ridiculously hard to analyse. It is weakly typed, and highly dynamic. For the last months, I have given myself the challenge to come up with a program which analyse jQuery and is able to retrieve the API. This is really hard. Most of the API is added with calls to jQuery.extend. >> Basically, a program would have to understand the semantics of jQuery.extend. But also understand that the output of $('a') has such prototype object with such properties. >> This is doable (since the WebStorm people do it), but very hard. >> >> If people have a syntax operator to perform an extend operation, well, that makes things infinitely easy to analyse, because it becomes part of the language. >> >> Another example: >> ---- >> var o = Object.create(null); >> ---- >> What is the o? If Object.create has not been redefined, it's an object. But it may be anything if Object.create has been redefined. Consequently, a JavaScript engine can never optimize this line (or may, but have to guard that Object.create hasn't been redefined which costs a little something) >> --- >> var o = null <| {}; >> --- >> Here, the semantics of this line is guaranteed by the language since this is syntax and not a function. Consequently, optimizations can be performed without risking to be compromised. >> >> Syntax additions make the language easier to analyse (allowing better tooling) and more stable so easier to optimize. Syntax may not be the concern of a part of the community, but is of another. >> Also, I'd like to mention that I'm pro-syntax addition when it covers things that would benefit from syntax (an extend operator, object literal additions...), but i won't feed discussions on syntax which do not bring anything else than readability, namely shorter function syntax. I have a preference, but do not care of the exact final syntax. I also do not really care of what the exact final syntax will be, but I do care that JavaScript contains more syntax for common patterns, especially the ones that helps analysis and optimizations. >> >> >> The JavaScript community is not one voice and doesn't have one unique set of needs. We use the language for different purposes. Some need crazy performance for awesome graphics/sound experience. Some need more stability to build tools (linters, IDE plugins, etc.). At JSconf.eu, Lea Verou mentionned during her talk that she loved Object.prototype.watch and that she wishes every browsers had this because it's helpful to write polyfills. Maybe it is time to restart the discussion on "observe" [1]. >> I wrote this paragraph because of the sentence "the only thing truly needed by this community now" in your (Andrea) post. >> "the only thing truly needed" does not exist. Maybe several people, maybe the majority of people want this. But other want other things and as long as it's justified, TC39 should address all of them. >> >> David >> >> [1] http://wiki.ecmascript.org/doku.php?id=strawman:observe > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
