Le 04/10/2011 18:51, Mike Samuel a écrit :
> 2011/10/4 David Bruant <david.bru...@labri.fr>:
>> 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
>>>
>>> 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.
> No it doesn't.
>
> Just walk the object graph starting from the root object and let the
> set of all reachable symbols be A.
> Load jQuery
> Walk the object graph again letting the set of all reachable symbols be B.
>
> The public API of jQuery is then (B - A).
I wish things were that simple.
----
var a = function(){
var c = function(){};
c.prototype = {/*put functions in here*/};
return new c();
}
----
a is part of your API, but all functions of c.prototype could be
considered as so as well (very close from the $('a').text function on
jQuery objects for instance, but jQuery is fine since $('a').text can be
found on jQuery.prototype) and you won't be able to figure it out unless
you call the function or are able to analyse the function body which is
what makes the analysis hard.
Good try though ;-)
For that matter, the best definition of an API in JavaScript I have come
up with is:
1) The set of properties added to the global object after running the
script
2) The set of properties added to the objects accessible from the global
object (often refered as "extending built-ins")
3) If one of the above is an object, its properties (own or inherited
through a prototype) are also considered part of the API.
4) If one of the above is a function and this function generates an
object, properties of this object are also part of the API.
5) Rules 3 and 4 are applied mutually recursively until reaching a fix
point.
And I'm not 100% satisfied with it yet. Ideas of improvement welcomed.
David
>
>
>
>> 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
>> 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
