Re: Thread about ES6 on reddit
On Aug 11, 2014 2:22 PM, Brendan Eich bren...@mozilla.org wrote: Christoph Martens wrote: But on the other hand I sold all my JS books, because they are worthless. Sorry you bought the wrong books. Try these: http://eloquentjavascript.net/ http://www.informit.com/store/effective-javascript-68-specific-ways-to-harness-the-9780321812186 /be Flanagan's Rhino book is excellent IMO. ___ 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: Generic Bundling
On Oct 13, 2013 4:40 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: On Sat, Oct 12, 2013 at 12:07 PM, Brendan Eich bren...@mozilla.com wrote: However, Russell's counter-argument that fallback in older browsers to loading lots of little files, request by request, from the server directory hierarchy, may be too painful, reducing the value as a migration technique. this is what happens today with external CDN scripts and/or AMD like solutions regardless ... if these are not bundled all together, isn't it? To me at least, the primary difference there is that in that case it is in the authors hand whereas native feature support is in the hands of the user agent, creating a potentially huge and unmanageable perf delta in the short/medium term. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 'function *' is not mandatory
Fwiw, just bikesheddingly speaking I actually prefer the *. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 'function *' is not mandatory
On Aug 31, 2013 6:20 PM, Brendan Eich bren...@mozilla.com wrote: Brian Kardell wrote: Fwiw, just bikesheddingly speaking I actually prefer the *. Let's review. Three reasons for function* syntax: 1. Opt-in required for backward-incompatible definition of 'yield' as low-precedence unary prefix operator. 2. Zero-yield (no yield in body) basis case, useful for delegation via yield* from another generator. 3. Decorator to alert the reader that the body contains yield (ignoring 2 for a moment) reason. You are bikesheddingly supporting 3, I take it. Can you say more about why you want a decorator for human readers? Again ignoring 2, which makes the case based on what the JS engine must see, a more objective criterion in this case (and, in a different light, in case 1). /be Yes. I know its not especially useful and i debated sitting it out (as i often do on this list) - i think #1 stands on it own, but I felt that there was some debate about the value of #3 which isn't for compatibility or even function but for developers, and perhaps it might be useful to say that given the choice between * and none, I'd prefer the visual queue that tells me its different with an easy scan because...It's bikesheddy - i know but I thought it worth saying that as one of those devs I think it has value. So if we can get 1 and 3 with a single char... Win. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 strawman: Array.prototype.fill and Array.prototype.move
On Jun 23, 2013 5:12 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 23, 2013, at 1:36 PM, Brendan Eich wrote: Allen Wirfs-Brock wrote: See http://wiki.ecmascript.org/doku.php?id=strawman:array_fill_and_movefor a strawman proposal for two new Array methods. These are proposed for inclusion in ES6. I updated the wiki: Discussion Q: Does anyone know of a rationale for why (start, end) might be a better design pattern than (start, count) for such operation? A: Array.prototype.slice uses (start, end) where end is a fencepost to facilitate looping over half-open ranges within a larger range. Spec’ing count requires subtracting next_start - end, gratuitously. Also, consistency with slice and range APIs matters. This should be considered carefully in the design. Yes, both start,end (slice) and start,count (splice) currently appears in Array methods so it isn't obvious which precedent to follow for best consistency. I could go either way. It would be nice to have a utilitarian-based argument for one or the other. Search result was it because of the -1. allen — /Brendan Eich mailto:%26%23x62%3B%26%23x72%3B%26%23x65%3B%26%23x6e%3B%26%23x64%3B%26%23x61%3B%26%23x6e%3B%26%23x40%3B%26%23x6d%3B%26%23x6f%3B%26%23x7a%3B%26%23x69%3B%26%23x6c%3B%26%23x6c%3B%26%23x61%3B%26%23x2e%3B%26%23x6f%3B%26%23x72%3B%26%23x67%3B 2013/06/23 20:31/ /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss I would like to propose that .move() smells funny. It implies things that are not so. It actually copies, and, while .copyRange suggestion from the wiki is better, it really -feels- like .copySlice() which answers the args question as well. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JSON Duplicate Keys
(Snipping out everything as this is a holistic response to the whole thread) Re: MUST / last value Agree, codify the de facto standard. That is what we do almost universally - it doesn't even actually break anything that already works - it just means those parsers aren't strictly conforming - they already aren't in keeping with the norm. . Re: Should allow comments / single quotes Perhaps if we went back in time and were discussing creating a new format, you might even convince Doug of some of this - what we wouldn't know is how that would affect adoption/development of compatible parsers, bugs, etc - and that is important given the next comment... . Re: The Web can't evolve if you can't...AND create something else, but don't call it JSON.. AND inventing crappy syntax JSON is maybe the single best proof that the Web can evolve without breaking anything... It started out competing with XML which had every advantage imaginable: it was a REC standard, had support from every big company, hundreds of libraries, had built in/native support in just about every language and was technically superior. JSON had simplicity and dev contributions. It competed in the real world and won hearts and minds against all odds. Now we have a standard of agreement - you can't break it. The Web is an enterprise of unparalleled scale, JSON is a data interchange format, so even more so than something that exists only in browsers...Anything that breaks potentially affects people's (not developers) lives in real ways and has to be done with great care. You can, however, follow the same model and beat it. In this case, if you have minor changes, it is even easy to make something that can transform to existing JSON format... If you do, we can easily make it native/standard - and you can expect that eventually someone will have similar criticisms and try to compete - that's a good thing. #extendthewebforward :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Coordination (was: ES6 Modules)
On Apr 12, 2013 11:06 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Apr 12, 2013 at 3:39 PM, Rick Waldron waldron.r...@gmail.com wrote: The DOM side should all be subscribed to es-discuss and read it on a regular basis. Additionally, our f2f meeting notes are a great way for them to keep up to date, as well as providing a good jump off for questions and concerns. Given the number of people working on platform APIs that should seems ever less likely to become a reality. We need a different strategy. Feels like some tc39 member(s) should be invited experts to anything @w3c dealing with scripted apis as a checkpoint and that w3c folks should at least follow es-summary and review f2f notes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fwd: Standardizing console APIs: Where?
Somehow this thread wound up forking only to public-script-coord at some point - not sure where. See comments from awb, alex russell, mark miller and others: http://lists.w3.org/Archives/Public/public-script-coord/2013JanMar/thread.html -Brian -- Forwarded message -- From: Robin Berjon ro...@w3.org Date: Wed, Feb 27, 2013 at 5:35 AM Subject: Re: Standardizing console APIs: Where? To: Brian Kardell bkard...@gmail.com Cc: public-script-co...@w3.org public-script-co...@w3.org On 26/02/2013 23:06 , Brian Kardell wrote: 1. Does anyone else feel like we _should_ have a standard I think that this thread has shown that there are interoperability issues. Given that this is a debugging tool, you really want it to have predictable behaviour so as not to waste time looking for a problem that in fact comes from the console API. 2. Given that this goes beyond the browser, where should that standard live? I feel like its proper home is ECMA since the API, again, has not really anything to do with browser necessarily. I think that it makes more sense in ECMA, but if for whatever reason that doesn't work out you're welcome to bring it to W3C. 3. If ECMA, is it part of the language (ES7?) or is it separate like i18n? I was actually suggesting that my opinion is the later, this feels like an ECMA module that could use standardization and is commonly imported in browsers and many engines for back-compat as 'console' (though I suggesting 'logging' is a better API term). I also suggested (in the strawman) that it could start _very_ small with the abstract APIs that are at least universally non-breaking (even if they might do something slightly different) and have been fermented for years and years - thus it should mostly be an easy approval to find a home and basis on which to gather proposals and consensus I don't have a specific opinion on how ECMA organises work, but I strongly agree with the idea of starting very small and iterating, even if it means that you release several version in a relatively short period of time. -- Robin Berjon - http://berjon.com/ - @robinberjon -- Brian Kardell :: @briankardell :: hitchjs.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing console APIs: Where?
On Wed, Feb 27, 2013 at 1:55 PM, François REMY francois.remy@outlook.com wrote: In browsers, when logging an object, you can actually click on an arrow to browse through all its properties. Serializing the whole thing on every single console.log, when those happen in a loop, would make the debugging experience a nightmare, performance-wise. True but we may expect the string representation to be exact while the details are loaded when expanded only. The clickable behavior is an extension to the Console API (which is text-only). I agree that this part should not be standardized. However, IE has a console.clear() function that I find useful, it should probably be standardized. I think we should also get console functions bound to the console object as it was already proposed in this thread. The string output format should probably be better defined, too. All in all, even if we limit the scope to text functions, there's still room for compatibility improvement. I wonder if the people working on navigation timing APIs wouldn't agree to work on this since the console API has profiling capabilities... which probably could be improved vastly. BTW it should be noted that some browsers only enable logging on a page if the console window is open (or was opened at some point in the page lifetime). This is maybe a way to avoid the slow down that more powerful logging tools could cause. All of this is why, if you look at my strawman, I proposed that it be a generic (logging) interface and focus on creating non-breaking APIs rather than go into too deep details about how/what it does with them since that is variable and contains of room for art and innovation. In other words, an API with complete noop implementations would actually be valid (logging is disabled). It could easily provide stricter advice/requirements where appropriate and keep this in tact. For example, since the de-facto apis allow tokenization, it seems appropriate to either suggest or even potentially require that if it does show those messages (if it is actually logging something) it should (or should not) serialize objects, which tokens are valid (%d, etc). This seems to me workable and simple to start pretty basic, release early and iterate quickly... That's all speculation on my part, of course, but it sounds rational to me :) -- Brian Kardell :: @briankardell ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing console APIs: Where?
I must admit i am a bit surprised that anyone would appear to be opposed to formalizing something through one of the two groups... It seems to me the goal of all of these other groups here is to pick up something that is lacking and people wish that we had a standard for. Regardless of history or agreement by vendors, no dev i know of looks to any of those as sources of standards and they give no indication themselves otherwise. I sent Rick the following link Friday evening and was hoping for a little tweaking before it was shared with a much wider audience. It contains explanation/goals/non-goals https://github.com/bkardell/logging Essentially though, some logging concept (usually console based) is supported by all engines, but the actual almost universally shared API has actually been pretty small. There is really no good reason i can see for that, logging really has nothing to do with dom or even console inherently - so why not get an actual standardized API effort to make the code at least universally portable with a source people can look up and recognize as standard? That said, i'm not interested in charging at windmills here, so if no one is interested, that's fine too. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Standardizing console APIs: Where?
Recently I read a post about Chrome adding a console.table API which mentioned some things in other browsers. My immediate reaction was is this a new proposal for addition to console standard API, because that could be pretty handy actually but then after a moments pause and about an hour search, I realized: There is no codified standard for console API. Turns out that public-browser-tools-test...@w3.org has sort of agreed to take it up, but it doesn't seem like anything much has happened yet and I'm wondering why that should be bound to anything with the browser since console is a pretty universal thing in implementations. Not saying it should or shouldn't be ECMA, just that it seems to be in the wrong place now if, indeed, anything is happening there. So what does everybody think? It seems that there is already a subset of what's implemented out there as a de-facto standard and could be some low-hanging fruit to create a base standard on which others could propose against, provide prollyfills for, etc - and that would be a pretty good thing IMO. Over the years, just a couple of anomalies in browsers have caused some pain - let's write it down somewhere :) -- Brian Kardell :: @briankardell ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: sort keys with JSON.stringify()
But Doug, just to clarify: You mean that the parsed objects create no
predictable insertion order right? It is actually possible to use replacer
to serialize keys in a particular order, and that might be enough for what
he is looking for (if two objects serialized as the same string they would
be equal).
Perhaps I am over simplifying his question or I misunderstand your response.
On Sep 11, 2011 3:05 PM, Douglas Crockford doug...@crockford.com wrote:
On 11:59 AM, Felipe Gasper wrote:
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
JSON objects are unordered. If order is important, then use an array.
___
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: sort keys with JSON.stringify()
I think depth shouldn't be the problem. At the crux of is is that that technique uses iteration order which has a bit of a defacto standard that would guarantee that certain classes of object would serialize objects with the same data in the same way. It has problems on the fringes though...if your data contains numeric keys or prototypes, for example. I say guarantee in quotes because sometimes a browser picks one of these things that isn't written up and bucks tradition... Sometimes they are punished because too much breaks, but sometimes not. On Sep 12, 2011 8:10 AM, Felipe Gasper fel...@felipegasper.com wrote: On 9/12/11 10:07 AM, Brian Kardell wrote: But Doug, just to clarify: You mean that the parsed objects create no predictable insertion order right? It is actually possible to use replacer to serialize keys in a particular order, and that might be enough for what he is looking for (if two objects serialized as the same string they would be equal). Almost. Actually, I want the converse: if two objects are equal, they serialize the same way. I noodled with the replacer function for a bit but wasn’t able to get something that seems to work for objects of arbitrary depth. -FG ___ 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: sort keys with JSON.stringify()
If you have non-numeric keys they should be in insertion order. Search the
archives, this is a much discussed topic.
On Sep 11, 2011 12:13 AM, Felipe Gasper fel...@felipegasper.com wrote:
But even that is implementation-specific, right?
Object key order can be completely random…at least, that’s always been
my understanding.
-F
On 9/10/11 9:32 PM, Cryptic Swarm wrote:
run it through something like this:
function sortKeys(obj) {
var ret = {}
Object.keys(obj).sort().forEach(function(name) {
ret[name] = obj[name]
})
return ret
}
before passing it to JSON.stringify
On Sat, Sep 10, 2011 at 9:14 PM, Felipe Gasper fel...@felipegasper.com
mailto:fel...@felipegasper.com wrote:
Hello,
Is it possible to get sorted keys:
{a:1,c:3}
…from running JSON.stringify when declaring an object thus:
{c:3,a:1}
??
-FG
_
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/__listinfo/es-discuss
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: Why not Profiles? (was: Bringing setTimeout to ECMAScript)
Im not a member of any group, but I follow closely and fwiw, I would like to offer an outside +1 to Brendan's comments above. Differences and versioning problems and things are going to arise naturally no matter how well things are planned, better to introduce as few of them upfront as possible (preferably none is the goal). On Mar 20, 2011 2:17 PM, Brendan Eich bren...@mozilla.com wrote: On Mar 20, 2011, at 9:14 AM, Mark S. Miller wrote: On Sun, Mar 20, 2011 at 8:56 AM, David Herman dher...@mozilla.com wrote: But that alone should probably not stop us from moving ahead with concurrency. If an engine wants to provide a sequential JS, they can probably just do so and say they're conformant with everything except for the concurrency parts. Or maybe we can highlight the concurrency parts of the spec and say a sequential JS doesn't have to implement them. I like this approach, so much that I changed the subject line ;). It gets us back into a practice that tc39 had and dropped before I joined, defining subsets or profiles of the full language as normative specs one could conform to. Last we checked, almost no one in TC39 wanted to take this on. ES5 strict is already a dialect of ES5 that has different runtime semantics, not just syntactic restrictions (early errors). Implementors are still rolling stones uphill to get it implemented correctly and to get errant sites evangelized and fixed. Adding more profiles just adds to the combinatorics, even if you try to nest profiles as subsets. More to check, more to go wrong, more work in committee now and in the field later (interop bugs), more time to complete the whole ES.next. Compound that over .next.next, etc. and you get path dependencies that can paint us into corners, magnifying mistakes. This path dependency exists no matter what, but the fewer profiles or versions, the better. Harmony of my dreams is an opt-in language close to JS today but with a handful of incompatible changes, almost all of them caught by early errors (typeof null === null is the current exception requiring more aggressive static analysis than a common implementation can afford, or all-paths test coverage). My SES work is essentially such a profile. Some CommonJS folks are considering requiring all CommonJS modules to be compat with ES5/strict, and treating them as such whether they say use strict or not. A server-side engine that dropped support for non-strict code could be much simpler. All of these seem like sensible profiles to give normative names to. So I was wondering, why has our common wisdom become to avoid standard profiles? Do these reasons apply to such cases? See above. I've been through this over the years in many context: X, PHIGS/PEX, *GL, MPEG, NFS. We can't avoid some amount of versioning over years and decades (even HTML is versioned by doctype). But we can certainly avoud jumping in with both feet to compound the problem (quadratically, worst case). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property Iteration in JSON serialization
On Tue, Oct 13, 2009 at 10:54 PM, Luke Smith lsm...@lucassmith.name wrote:
On Oct 13, 2009, at 9:24 PM, Brian Kardell wrote:
There are potentially some additional practical upshots beyond human
readability to this which I won't get into here until I find out: Is
it even plausible to accomplish this with new built in JSON supports?
To be specific, if it's not clear... Given an instance of an order
object, I would like to serialize it like this:
{
items: [
{
description: A bottle of rum,
itemId: 13523,
price: 12.94,
quantity: 6
},
{
description: A bottle of whiskey,
itemId: 23423,
price: 6.95,
quantity: 24
}
],
orderNumber: 1234123,
shipTo: {
city: Seattle,
name: Jane Doe,
state: Washington,
streetAddress: 123 Main Street,
zip: 12345
}
}
It is possible to sort object keys in a replacer function. See
http://gist.github.com/209826
Currently FF3.5.4 doesn't properly apply replacer functions, but Safari 4,
WebKit, IE8, and Chrome 3 work fine for this task.
Luke
But I guess your example gets to the gist (ironically, given the url)
of the question: It seems to be implying that there is a specific
(insertion) order maintained by the instance itself and reflected in
iteration... The difference being something more like a TreeMap than a
HashMap - but is that part of the specification? I thought that it
specifically wasn't.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Property Iteration in JSON serialization
On Wed, Oct 14, 2009 at 5:41 AM, Patrick Mueller pmue...@yahoo.com wrote: On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote: All ES implementations are required to enumerate object properties in the order of insertion, regardless of internal representation, and the JSON object definition defines the replacer execution in terms of that standard object enumeration. I understand that's what all (or most) of the implementations actually do, but the ES5 spec I'm looking at - Ecma/TC39/2009/043 - doesn't actually say it's required. In 12.6.4 discussing the for-in statement, it says: The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified. In 15.2.3.14 discussion Object.keys(), it says: If an implementation defines a specific order of enumeration for the for-in statement, that same enumeration order must be used in step 5 of this algorithm. In 15.12.2 discussing JSON.parse(), it says: The ordering of the Strings should be the same as that used by the Object.keys standard built-in function. In 15.12.3 discussing JSON.stringify(), it says: The ordering of the Strings should be the same as that used by the Object.keys standard built-in function. Sorry, property ordering is an unfortunate pet peeve of mine. :-) Patrick Mueller - http://muellerware.org/ Uh oh... Patrick looking at the same parts as me reacting the same way (I believe older pre-5 docs also said something similar)... When Oliver said All ES implementations are required to... I assumed that I missed something in the new 5 docs - not that everyone just seems to have implemented roughly the same thing... Is it required - or is it not? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property Iteration in JSON serialization
Sure, but again... Without any changes it currently reads: The mechanics and order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is not specified. Which isn't really necessary even currently (pre-5 I think) doesn't accurately describe what seems to be the de-facto standard. It should be relatively easy to merely codify what is already implemented everywhere which sounds like without any disagreement or new proposals it could say something along the lines of: For objects containing no indexed properties the mechanics and default order of enumerating the properties (step 6.a in the first algorithm, step 7.a in the second) is specified as insertion order. For reasons of historical compatibility, the default order of enumerating the properties of objects which contain indexed properties is not specified. That's not to say that no further effort should be made to take it even further, but I for one would find something like the above a lot more comforting and realistic than nothing at all if it comes to that. On Wed, Oct 14, 2009 at 7:01 PM, Allen Wirfs-Brock allen.wirfs-br...@microsoft.com wrote: It's probably too late for us to take advantage of this, but it did just occur to me (too much document.all discussion) that since for-in is a syntactic construct its behavior could be different in strict mode, potentially allowing us to define a for-in enumeration order that isn't tried to legacy behavior. Similarly, rather than trying to fully specifying for-in enumeration order (and invariably causing potentially breaking changes for some implementations) we could specify a new enumeration statement that uses a strictly specified order. By suggest for this would be: for names (n in expr) ... and for values (v in expr) ... avoiding conflicts with the existing for-in and E4X for-each. Allen -Original Message- From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org] On Behalf Of Mike Shaver Sent: Wednesday, October 14, 2009 6:30 PM To: Waldemar Horwat Cc: es-discuss Subject: Re: Property Iteration in JSON serialization On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat walde...@google.com wrote: No. As I wrote, there is no de-facto implementation order because the implementations do not agree on the order in general, and what you call fringes such as numbers do matter. Trying to force, say, insertion order would likely break compatibility. IIRC, Firefox before FF3 used insertion order for arrays as well as objects, and changed to index order for arrays in FF3. I don't recall any compat problems on either side of the transition with respect to array iteration order. Mike ___ 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: Property Iteration in JSON serialization
Sorry... somehow Waldemar's comment got closed up in my Gmail conversation stack and I missed this comment... If Oliver and Hallvord and Brendan are wrong on the idea that it is at least largely already a de facto standard for non-indexed properties then I suppose it is a moot point... On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat walde...@google.com wrote: Brian Kardell wrote: It sounds to me like there is wide agreement in the sense that at least the basics rules and only disagreement on the fringes... Otherwise no one on this list in particular would be suggesting that there is anything remotely like a de facto implementation... It seems that at least those basic rules are required just to function with the existing expectations everywhere. It also seems that those expectations aren't likely to change any time soon for the default for-each iteration order whether more robust and interesting proposals are adopted... So can't that much be formalized and documented regardless of whether or not new introductions are made to over-ride other predictable iterators to be used in for-each (or perhaps even some new mechanism entirely)? The simple fact that conforming to the spec would currently create a non-workable solution seems to argue that at least the de facto parts should be included... No? No. As I wrote, there is no de-facto implementation order because the implementations do not agree on the order in general, and what you call fringes such as numbers do matter. Trying to force, say, insertion order would likely break compatibility. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 10:36 AM, Aaron Gray [EMAIL PROTECTED]
wrote:
On Dec 2, 2008, at 5:31 AM, Aaron Gray wrote:
i still prefer 'lambda (a,b,c) { ... }' as it is readable to the
uninitiated and can then at least give a handle for someone to lookup.
I think the truly uninitiated would not find lambda any more obvious in
meaning than \ or ||.
People can google lambda they cannot google \, or ||. Also keywords
seem better suited to Javascript syntax.
Aaron
Is the argument that the uninitiated should be able understand complex code
concepts via a google search of the thing that they don't understand?
There are already all kinds of things that one couldn't understand via a
simple google search for something in the code, and which people of various
levels of experience might experience: Object literals come to mind or ||
and as guard/default, ? as ternary if, or even ++ or %= and there
are plenty more things which might or might not have a readily identifiable
thing to allow someone to google for like default values, coercion rules, or
scoping concepts.
Google is an excellent tool, but I don't think that it's necessarily a great
way to interpret code into something understandable to the uninitiated.
Doesn't seem like a good deciding factor.
___
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
