Re: death to style guidelines
I do understand that just switching a skin is no go, but having something like: use clean; Could be a very good compromise. Regarding my phrase on coffee: I did not meant to heart anybody's feelings regarding coffee script. I do like the project myself but I don't think it production ready. Here is the quote from the coffee script website: *Disclaimer:* CoffeeScript is just for fun. Until it reaches 1.0, *there are no guarantees that the syntax won't change between versions.* * *Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France http://goo.gl/maps/3CHu On Thu, Sep 2, 2010 at 10:52, Dmitry A. Soshnikov dmitry.soshni...@gmail.com wrote: On 02.09.2010 2:44, Mike Samuel wrote: 2010/9/1 Irakli Gozalishvili rfo...@gmail.com rfo...@gmail.com: I have not seen the post before, but it perfectly expresses my concerns. I still do think though that if breaking backwards compatibility is on the table solving syntactic noise issue is not such a bad idea even if it means changing a skin it makes devs more aware of a change. Both skulpt coffee are good toys, but don't think it's practical to use them for a real apps. Actually, CoffeeScript is off-topic here. When I was mentioned it, I didn't mean let's make a Coffee from JS, I just noticed how elegantly Coffee improves some syntactic constructs over JS. However, I'd like to mention that -- you're kidding me, right (about the toy without practical usage)? Coffee is a new language. And the only relationship with JavaScript, is that it's inspired by JavaScript (but actually by Ruby) and improves some constructions (syntactically and, as a consequence, increasing and abstraction). It's good to write a new highly-abstracted language, using another highly-abstracted language (in this case JavaScript). If will be needed (if will be talks about performance), it may be rewritten using less-abstracted languages (e.g. C, Assembler) and then it will be a completely separated from JavaScript language which is (the same as JavaScript, Python, Ruby, etc.) just another good general purpose scripting language -- with its own pros and cons. Moreover, CoffeeScript syntactically mostly inspired by Ruby (in it's nature, Coffee isn't even prototype-based, it encapsulates this stuff into the sugar of classes; JavaScript is used only to implement Coffee. And as you know, the latest version of Coffee is already written on Coffee itself but not on JavaScript). If it will have a strong support (by committees, browsers, etc), it may win JavaScript. But I don't think it will in nearest future (the same useless talks about Python and Ruby native support in nowadays for browsers). However, if not to translate/compile Coffee's code into JS-code at runtime, but with static preprocessing -- having as an output ready JS-code-generated files, and then just include these js-files to the project -- it normally may be used in projects today. There is a lack with debugging in this case, but I think it may be solved somehow. And regarding JS, yeah, backward compats matter and it's really not-practical to switch the skin so radically. However, since ES has use strict feature which is, besides being a helper for inattentive programmer, also is used as a deprecated/obsolete stuff notifier (e.g. with-statement), it may be used in future for the same role -- removing old-style/deprecated syntactic garbage, and replacing it with alternative constructs. (Because e.g. when C was creating its switch-cases with known today non-logical behavior, its decision was related with *problems and issues* of code-generation (e.g. in Assembler) -- it was needed that break, because it's just a jmp from the block. But when other languages (Java, JavaScript) just repeat this syntax construct completely after C, they just thought about to be a new language with already-known syntax. And attempts to improve some constructs of previous language, would break this aim). P.S.: I'm really sorry for such a big off-topic. BTW blessing one of the coding styles as Dmitry suggested may be a successful attempt for solving at least half of the issue. Might blessing a style guide be better done by a software producing organization like Mozilla or JQuery than by a standard producing organization like TC39? Yeah, right... But, since there is a (formal?) language named ECMAScript, maybe it worth to write at least some *recommendation* for a coding style. At least with naming convention of properties/methods. The spec itself prompts a programmer that methods should be named in camelCase, that constructors should be named in upper CamelCase, etc. If an official site of the technology will have such a recommendation (I repeat, even Python with it's hard-coded syntax rules has additionally PEP8 -- to (recommend to) name properties/methods in uderscore_case), then we'll see that many companies when
Re: Object.eq is ready for discussion
FWIW: Clojure (the new Lisp) uses (identical? a b) I don't know why Rich Hickey dropped 'eq?' and went with 'identical?', but I like it. Cheers, Tom 2010/9/7 Brendan Eich bren...@mozilla.com On Sep 7, 2010, at 9:34 AM, Ash Berlin wrote: On 7 Sep 2010, at 17:18, P T Withington wrote: On 2010-09-07, at 12:02, Brendan Eich wrote: 3. identical If I had a vote, +1 Is there someplace that concisely explains the cost of just fixing `===` so I could understand why that is not a choice? FWIW this sort of naming issue is a rabbit hole that CommonJS fell down when it came to method names for a unit test framework[0]. There was no real consensus, but we settled on equal meaning == and strictEqual meaning ===. Those are fine names, and it seems you came out of the rabbit hole (under the bikeshed ;-). All naming discussions can rathole (let's say), but I hope we can conclude this thread with a clear winner, as it seems you guys ultimately did. Also, you picked spec-like names for == and === but there is no SameValue or Object.eq, I take it (even though one can be written in JS). If you had such a thing, I wonder whether you wouldn't name it identical (not reallyStrictEqual or sameValue). But I don't want to send you back down the hole to find out! This es-discuss hole will do. /be ___ 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: Classes as Sugar is now ready for discussion
On 2010-09-05, at 10:33, Mark S. Miller wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar Of the three straw contenders for this niche, my preference order continues to be * Traits If I had a vote, it would be +1 * Classes as Sugar * Enhanced Object Literals But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I have now finally put the Classes as Sugar strawman on the agenda for consideration by the committee. It is now ready for discussion. This: Inheritance using the prototype chain does not work since the members are added to the instance and not the prototype. This makes this proposal non compatible with existing JavaScript paradigms. This in turn leads to classes becoming something completely new that exists on the side of existing best practices of doing OOP in JS. seems damning, without further explanation. Enough so that I would say the proposal should not use the word class to describe what it does. From a users point of view, it is baffling why you would want to standardize something so non-standard, when there is a clear call from use cases for a standard for doing normal OOP in Javascript. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Wed, Sep 8, 2010 at 10:16 AM, P T Withington p...@pobox.com wrote: On 2010-09-05, at 10:33, Mark S. Miller wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar Of the three straw contenders for this niche, my preference order continues to be * Traits If I had a vote, it would be +1 * Classes as Sugar * Enhanced Object Literals But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I asked MarkM off-list what the reason was, and he replied that there was an objection (raised by Waldemar?) to how class evolution was handled. Namely, that adding a property P1 to trait X can cause a cause a conflict in other downstream code that was already composing X with Y where Y already had an independent property named P1. In response to this, I outlined several possible ways forward: 1) pretend this issue doesn't exist and soldier on, 2) don't add traits, 3) perform automatic resolution in some sort of defined order based on declaration (e.g., the C3 MRO algorithm that Python et. al uses), 4) perform automatic resolution based on some sort of runtime ordering (e.g., last method added wins), (I'm not sure that this is actually different from #3) 5) raise an exception when the conflict is detected, thereby forcing the author to specify resolution (perhaps less appealing since we don't necessarily have a compile phase to catch these errors at on a web page). Since the first option is surely unacceptable, and we'd like to not have to settle on the second, that leaves the others. Most of the people I've polled (including Tom van Cutsem) indicate a preference for #5; Tom indicated that he thought one of the major goals of traits was to avoid any sort of automatic resolution algorithm. Some are unclear how much this will be a real problem in practice, and were inclined to think that it shouldn't stop authors from being able to use this (I'm probably paraphrasing incorrectly here), as long as they are able to detect and recover from these issues. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I asked MarkM off-list what the reason was, and he replied that there was an objection (raised by Waldemar?) to how class evolution was handled. My feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Wed, Sep 8, 2010 at 12:52 PM, David Herman dher...@mozilla.com wrote: But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I asked MarkM off-list what the reason was, and he replied that there was an objection (raised by Waldemar?) to how class evolution was handled. My feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. Does that feeling carry over to any variants that might actually include new syntax? -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Sep 8, 2010, at 12:52 PM, David Herman wrote: But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I asked MarkM off-list what the reason was, and he replied that there was an objection (raised by Waldemar?) to how class evolution was handled. My feeling, and I think the feeling of others at the meeting when we discussed traits, was that traits.js is a very nice library but that it doesn't offer enough to the language to warrant standardization, at least yet. The fact that there would be performance benefits to built-in implementations of traits isn't enough to make the case. IMO, libraries should generally be very widely used and very stable before they are added to the ES standard library. The specific objection articulated by Waldemar was the version evolution problem, where a downstream client and upstream library evolve independent, conflicting traits. If I remember Waldemar's point correctly, he wants version 1 library users to be shielded from any conflict between their client code, however it evolves, and version 2 of the library, however it evolves. AFAIK this is nowhere near a solved problem in PLT. The general objection, or more accurately, recommendation (since everyone I know thinks highly of Mark and Tom's http://traitsjs.org work), was what Dave said: the code was too good as library code to win hardcoding in dedicated syntax in a near-term edition of ECMA-262. I pointed out on this list that JS VMs have a hard time optimizing traits' shared methods -- really, optimizing away multiple function objects resulting from evaluation of a single nested function expression or definition: https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html But this problem can be solved by an extension such as http://wiki.ecmascript.org/doku.php?id=strawman:const_functions Specifically the bit I proposed at the July TC39 meeting at Microsoft, which Mark nicely wrote up in detail at http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining So if traits.js does not need syntax to be optimized, it still might merit syntax for usability. But we would need more experience with it, and a larger user base for it, before standardizing. We in TC39 generally hesitate to standardize library code. We certainly extended the JS standard library in ES5, but notably with JSON, which is a fixed spec that will never change (only be replaced some day, Doug says -- that day is far off, I say). The ES5 meta-programming API was a synthesis and extended rationalization of precursors such as getters and setters including their __ APIs (__lookupGetter__, etc.) first added by Mozilla over ten years ago, and cloned into other browsers. Function.prototype.bind was a common feature of JS libraries, although not always the same and we're only now finding conflicts (with MooTools, which is adapting to avoid the conflict, IIRC). This was more than enough library extension for ES5, and with implementations only rolling out now in betas or preview releases, the verdict on how well we did is not yet in. I am sympathetic to objections of the form Ecma TC39 should not under-evolve the language and its standard library and thereby require all developers to develop and download big non-standard libraries, but it is not the only consideration. On the other side, library standardization should never be rushed. Just look at what happened with C! We really do not have the competence in TC39 (no one group does, yet, IMHO) to standardize JS library code aggressively. There are indeed notorious language and library gaps to fill, but we are focusing on the language gaps, with the Scheme philosophy of adding missing primitives that compose well and have good general usability and safety, while treading carefully with the library gaps. Traits could be part of the standard library at some point if they become popular to the same degree as JSON or bind, and provided we can overcome Waldemar's objection. Waldemar has been concerned with the version evolution problem since the original JS2/ES5 days. But we failed to solve it with ES4, so I'm not going to hold out for utopia (no-place). JS is a worse-is-better language, too much so, but getting over it. JS is never to be a superb better-is-better (which usually means never-is-better, which means users hacking library and app code have to reinvent wheels constantly) language. Parting shot: I find the zero-inheritance classes-as-sugar proposal to be lukewarm beer, and want to spit it out. I'm with Tucker. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com wrote: libraries should generally be very widely used and very stable before they are added to the ES standard library. That would seem like an unfair penalty. Am I to infer classes-as-sugar OS preferred because it _can't_ be implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
Does that feeling carry over to any variants that might actually include new syntax? The issue isn't whether it introduces new syntax, it's whether it introduces new semantics. The Traits library, as written, is completely implementable as a library in the existing language. That's not to say that we should *never* add new already-implementable libraries to the standard. Sometimes they fill an obvious hole (like Array.prototype.forEach), or they are clear, stable, and popular (like JSON). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Sep 8, 2010, at 2:37 PM, P T Withington wrote: On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com wrote: libraries should generally be very widely used and very stable before they are added to the ES standard library. That would seem like an unfair penalty. Am I to infer classes-as-sugar [is] preferred because it _can't_ be implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? I would not say classes-as-sugar is preferred by everyone on TC39. Waldemar favored it over against traits so Mark went back to the wiki salt mine to work on it. Hard to say what will happen here -- possibly something else (object initialiser extensions). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Wed, Sep 8, 2010 at 2:39 PM, David Herman dher...@mozilla.com wrote: Does that feeling carry over to any variants that might actually include new syntax? The issue isn't whether it introduces new syntax, it's whether it introduces new semantics. The Traits library, as written, is completely implementable as a library in the existing language. Agreed; perhaps my question was not clear. If there was a Traits-like proposal that did include new syntax, would you be against it because you can implement something similar as a library without needing new semantics, or would you be more inclined to reserve judgement until you could actually review a proposal and see what the proposed benefits were? -- Dirk ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
libraries should generally be very widely used and very stable before they are added to the ES standard library. That would seem like an unfair penalty. Am I to infer classes-as-sugar OS preferred because it _can't_ be implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? No. But keep in mind that nobody's denying anyone of the traits library. Go to http://traitsjs.org and use it today! :) IOW, I think it's better to focus on the things that can't otherwise be done in user code. Blessing certain existing libraries with possibly-more-performant C++ implementations is not a good use of committee resources, and it's a bad way to release and rev software since it's so much more encumbered by process. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
Agreed; perhaps my question was not clear. If there was a Traits-like proposal that did include new syntax, would you be against it because you can implement something similar as a library without needing new semantics, or would you be more inclined to reserve judgement until you could actually review a proposal and see what the proposed benefits were? The latter (speaking for myself, of course). Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
On Tue, Sep 7, 2010 at 7:21 PM, Brendan Eich bren...@mozilla.com wrote:
Anyone know of bad advice somewhere, or a code generator doing the prepending,
or anything else we should evangelize aggressively either to stop pasting
use strict;
blindly, or do do the testing to make sure the code passes in a conforming ES5
implementation
JSLint.com (which is an awesome tool that I use pretty much every day)
tells you to add use strict if you choose the Good Parts option.
Its documentation says to use it wisely, but people don't usually
read the docs.
Maybe JSLint should be fixed to disallow non-strict code with use
strict;. The following code is said to be OK by JSLint with Good
Parts at the moment:
/*global window */
use strict;
function someFun() {
window.alert(arguments.callee);
}
someFun();
I'm not sure whether people often run concatenated scripts through
tools like JSLint, though. So maybe it should also warn you not to
concatenate scripts blindly...
PS. I already wrote most of the above in the Intel bug in Mozilla's
Bugzilla, but now I think posting it here makes more sense.
--
Marek Stępień
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
The other problem with JSLint is that it can't run all of the code so JSLint
won't pick up the runtime error in
function f() {
use strict;
return this.foo;
}
f();
I've seen a couple of sites that would break due to this.
--Oliver
On Sep 8, 2010, at 3:16 PM, Marek Stępień wrote:
On Tue, Sep 7, 2010 at 7:21 PM, Brendan Eich bren...@mozilla.com wrote:
Anyone know of bad advice somewhere, or a code generator doing the
prepending,
or anything else we should evangelize aggressively either to stop pasting
use strict;
blindly, or do do the testing to make sure the code passes in a conforming
ES5
implementation
JSLint.com (which is an awesome tool that I use pretty much every day)
tells you to add use strict if you choose the Good Parts option.
Its documentation says to use it wisely, but people don't usually
read the docs.
Maybe JSLint should be fixed to disallow non-strict code with use
strict;. The following code is said to be OK by JSLint with Good
Parts at the moment:
/*global window */
use strict;
function someFun() {
window.alert(arguments.callee);
}
someFun();
I'm not sure whether people often run concatenated scripts through
tools like JSLint, though. So maybe it should also warn you not to
concatenate scripts blindly...
PS. I already wrote most of the above in the Intel bug in Mozilla's
Bugzilla, but now I think posting it here makes more sense.
--
Marek Stępień
___
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: use strict; prepended blindly to scripts in the wild
in the Names strawman, private foo at the top level has the same problem as use strict at the top level. maybe there should be a general way of delimiting a top-level lexical scope, so that pasting js together is still relatively easy? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
On Wed, Sep 8, 2010 at 6:25 PM, felix feli...@gmail.com wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively easy?
{
use strict;
/* strict code */
}
Not sure if this is legit -- I seem to recall something about use strict;
being scoped at the block level (or at least that you can scope a specific
if block). If so, wouldn't this suffice?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
2010/9/8 Dean Landolt d...@deanlandolt.com:
On Wed, Sep 8, 2010 at 6:25 PM, felix feli...@gmail.com wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively easy?
{
use strict;
/* strict code */
}
Not sure if this is legit -- I seem to recall something about use strict;
being scoped at the block level (or at least that you can scope a specific
if block). If so, wouldn't this suffice?
It is legit, but the use strict there is a string literal not a
prologue directive since those can only appear at the start of a
program or a function body.
___
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: use strict; prepended blindly to scripts in the wild
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem as
use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively easy?
Today, module pattern:
(function () {
// use strict or private x; here without fear...
})();
Tomorrow, with http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules,
something like
module {
// use strict or private x; here without fear...
}
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
Until JSLint actually enforces ES5 strict mode, its docs should not be
promoting use strict.
In the SVG past, the dark ages so to speak, some popular tools generated
invalid SVG-in-XML, and so did hand-coding authors. This begat missing xmlns=
declaration error correction. Same story as HTML quirks mode, which goes back
to when NCSA Mosaic had to keep content on ~80 web servers working even if it
was not well-formed (from personal communication with Marc Andreessen).
Are there 80 servers worth of content that has use strict but does not
conform to ES5 strict mode? Can we evangelize them? See the Mozilla bugs cited
in this thread, which are Technology Evangelism bugs, and kudos to Intel for
its rapid response.
But JSLint shouldn't be writing checks it can't back that its users will want
to cash in ES5-conformant browsers.
/be
On Sep 8, 2010, at 3:19 PM, Oliver Hunt wrote:
The other problem with JSLint is that it can't run all of the code so JSLint
won't pick up the runtime error in
function f() {
use strict;
return this.foo;
}
f();
I've seen a couple of sites that would break due to this.
--Oliver
On Sep 8, 2010, at 3:16 PM, Marek Stępień wrote:
On Tue, Sep 7, 2010 at 7:21 PM, Brendan Eich bren...@mozilla.com wrote:
Anyone know of bad advice somewhere, or a code generator doing the
prepending,
or anything else we should evangelize aggressively either to stop pasting
use strict;
blindly, or do do the testing to make sure the code passes in a conforming
ES5
implementation
JSLint.com (which is an awesome tool that I use pretty much every day)
tells you to add use strict if you choose the Good Parts option.
Its documentation says to use it wisely, but people don't usually
read the docs.
Maybe JSLint should be fixed to disallow non-strict code with use
strict;. The following code is said to be OK by JSLint with Good
Parts at the moment:
/*global window */
use strict;
function someFun() {
window.alert(arguments.callee);
}
someFun();
I'm not sure whether people often run concatenated scripts through
tools like JSLint, though. So maybe it should also warn you not to
concatenate scripts blindly...
PS. I already wrote most of the above in the Intel bug in Mozilla's
Bugzilla, but now I think posting it here makes more sense.
--
Marek Stępień
___
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: use strict; prepended blindly to scripts in the wild
On 9/8/10 17:25, Brendan Eich wrote:
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem as use
strict at the top level. maybe there should be a general way of delimiting a top-level
lexical scope, so that pasting js together is still relatively easy?
Today, module pattern:
(function () {
// use strict or private x; here without fear...
})();
that's not quite the same thing since the innards can't introduce new
top-level bindings. you can't just wrap an arbitrary js file in the
module wrapper and still have it work. you have to rewrite it.
I guess the transformation could be automated, though it's a bit more
complex than just concatenation.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
On Sep 8, 2010, at 6:34 PM, felix wrote:
On 9/8/10 17:25, Brendan Eich wrote:
On Sep 8, 2010, at 3:25 PM, felix wrote:
in the Names strawman, private foo at the top level has the same problem
as use strict at the top level. maybe there should be a general way of
delimiting a top-level lexical scope, so that pasting js together is still
relatively easy?
Today, module pattern:
(function () {
// use strict or private x; here without fear...
})();
that's not quite the same thing since the innards can't introduce new
top-level bindings. you can't just wrap an arbitrary js file in the module
wrapper and still have it work. you have to rewrite it.
That's true, and there's no way around it. But you can't create global
variables by assignment in ES5 strict mode. If your code section really needs
to create global bindings, even if properly via var and function (never by
assignment), then it's likely you don't want use strict; at the top of it.
You could use strict in each top-level function, but what if you have 930
functions in your code section? Better to use a module pattern and export
object for now (more below), and simple modules later.
I guess the transformation could be automated, though it's a bit more complex
than just concatenation.
There's no easy way to support concatenation and use strict (or private x).
But the ease of concatenative programming in JS is an illusion already.
Accumulating properties in the global object is a constant source of bugs and
confusion. Modern JS libraries minimize their global binding sets.
One nice way to minimize (sorry if this is old hat):
var exports = (function () {
// everything else here
return {...};
};
This enables use strict coverage of all the code in the module pattern that
returns the exports object. Of course you'd want to prefix exports, or do
something that avoids binding even one global var.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
On 9/8/10 18:52, Brendan Eich wrote: There's no easy way to support concatenation and use strict (or private x). But the ease of concatenative programming in JS is an illusion already. Accumulating properties in the global object is a constant source of bugs and confusion. Modern JS libraries minimize their global binding sets. right. but it's common for sites to develop with separate js scripts as modules and then combine them into a single script for speed when deployed to end-users. global conflicts can be found and solved when the js scripts are included separately, and naive concatenation does not change how the scripts behave. except file-level directives like use script change that. now I need to either - test the concatenation. - use a smarter rewriting-concatenator, which is probably complex enough that the result will need testing anyway. - validate the individual js files as naive-concatenation-safe before doing the concatenation. this probably should happen even if I use the module-with-exports pattern in my code, since who knows if some other js lib I use has file-level directives or not, and it's no fun to inspect it manually on every update. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
On 9/8/10 19:08, felix wrote: On 9/8/10 18:52, Brendan Eich wrote: There's no easy way to support concatenation and use strict (or private x). But the ease of concatenative programming in JS is an illusion already. Accumulating properties in the global object is a constant source of bugs and confusion. Modern JS libraries minimize their global binding sets. right. but it's common for sites to develop with separate js scripts as modules and then combine them into a single script for speed when deployed to end-users. global conflicts can be found and solved when the js scripts are included separately, and naive concatenation does not change how the scripts behave. except file-level directives like use script change that. now I need to either - test the concatenation. - use a smarter rewriting-concatenator, which is probably complex enough that the result will need testing anyway. - validate the individual js files as naive-concatenation-safe before doing the concatenation. - or js could barf/warn on file-level directives, basically making the previous option built-in. - or js could invent some way for me to say this is the end of the scope of a file-level directive within a single file. this probably should happen even if I use the module-with-exports pattern in my code, since who knows if some other js lib I use has file-level directives or not, and it's no fun to inspect it manually on every update. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict; prepended blindly to scripts in the wild
I recently asked Kris Kowal what he recommends as the simplest way to write
simple JS modules today that can be used either as browser-side scripts or
as CommonJS modules. Adapting the elegant pattern he showed me, I suggest
the following variation:
foo.js
---
(function(require, exports) {
use strict;
// ...
exports.x = 21;
}).call({},
typeof require === 'function' ? require :
function(id) { return this[id]; },
typeof exports !== 'undefined' ? exports : (this.foo = {}));
--
bar.js
--
(function(require, exports) {
use strict;
var foo = require(foo);
// ...
exports.y = foo.x * 2;
}).call({},
typeof require === 'function' ? require :
function(id) { return this[id]; },
typeof exports !== 'undefined' ? exports : (this.bar = {}));
--
In a CommonJS environment, require and exports would be defined and
require would be a function, so the first branches of the ?:s above would
be taken. In a browser-side environment, they wouldn't be defined, so the
second branches would be taken. In a CommonJS environment, loading bar.js
would cause the loading of foo.js. In a browser-side environment, the page
would still have to manually include these scripts in bottom-up order as
usual -- first foo and then bar. This works whether foo.js and bar.js are
included as separate scripts or whether they are appended together. Fancier
adapters like http://requirejs.org/ do more but need more setup. When the
simple pattern above is adequate, it works without any prelude or
infrastructure.
Everything above should work on old ES3 browsers. On ES5 browsers, each
individual module is strict, without the strictness leaking when module
sources are appended.
The main limitation for browser-side use is that the module names become
global variable names, and so potentially conflict with other global
variable names.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
