slightlyoff

Hi gruseom:

I'm the author of the original post.

There seems to be some serious (willful?) misunderstanding here about what is being proposed. Instead of adding something foreign, the class syntax that we've nearly got settled is sugar for what we usually write in JS, albiet under a dozen or so different patterns and library conventions. See: http://infrequently.org/2011/09/why-class-doesnt-mean-what-y...

I'm also not suggesting that length of debate necessitates action. The near-consensus on the committee for adding classes isn't my doing; I'm merely arguing that it's worth doing a smaller thing and debating what extensions to make in due time. And if you look at what's being added (again, I'm not sure you have a grasp on it in any way), it's clear that we are doing no harm with Max/Min classes.

Invoking Java to describe what's being proposed is purely a slur. Indeed, the arguments which I'm attempting to talk down are the ones which would drag a class proposal more towards Java (not less).

What's frustrating, in the end, is to see someone so obviously smart making such spurious arguments. Please read up before engaging further: http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...

Regards

#1 is just FUD. JavaScript is JavaScript. Class in JS is a shorthand for function and functions prototypically delegate. That you're not writing in Java/Python/C#/Ruby should be pretty obvious.

#2 doesn't bear much relationship to reality. There will be near zero correlation between "class" and performance. What can (and today, does) change the performance of objects is having their shape change markedly after construction. V8, for instance, already includes heuristics to know when a class is "done" being constructed, allowing it to apply most of the typed-language tricks in the bag for objects which are entirely unfrozen. In current code, it's actually a de-optimizer to call Object.freeze() and there's no reason to think you'll get anything faster for using "class" than by writing code which doesn't change its shape very much.

You will, however, finally be able to read and share code more easily.

Wait, you don't think accounting is a creative sport? Hmmm.

Mihai covered it. Here's my rundown:

http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...

It's likely that my understanding of the situation is at least partially confused. The "SuperFetch" branding covers a lot of systems with some observably complex interactions. From my recollection of the XPerf traces, we saw misses 10+ MB back in the DLLs and just ascribed it to "SuperFetch" on the front half.

If you could tell me if that's causal, it'd be awesome = )

Define "logical internal structure"? Most code in a library won't be differentiated by use unless you can provide WPO or PGO-based feedback that you trust as representative. As for the next obvious question ("why not just read in the whole thing?"), I think you can probably guess.

I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.

SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries. I implemented a similar solution for chrome.dll last summer and it had a gigantic effect on cold start times. Glad to see Mozilla prioritizing startup too.