Last Comment Bug 551529 - Remove __count__
: Remove __count__
: dev-doc-complete
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
-- minor (vote)
: mozilla1.9.3a4
Assigned To: Jeff Walden [:Waldo] (remove +bmo to email)
: Jason Orendorff [:jorendorff]
Depends on: 620344
  Show dependency treegraph
Reported: 2010-03-10 11:42 PST by Jeff Walden [:Waldo] (remove +bmo to email)
Modified: 2010-12-24 08:13 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

KILL THEM (4.95 KB, patch)
2010-03-10 14:27 PST, Jeff Walden [:Waldo] (remove +bmo to email)
shaver: review+
Details | Diff | Splinter Review

Description User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-03-10 11:42:48 PST
The appeal, at least as I understood it, is that it allows you to quickly and efficiently determine the number of own properties of an object, without some sort of ungainly loop structure.  That said, it seems it isn't actually "efficient", at least in the sense of not being O(n) in the number of properties on the object, for normal JS objects, because it uses the mechanism of initializing an enumerator to get the property count -- but initializing an enumerator iterates through all properties!  So either way you still have this linear-time loop; the question is whether it's hidden behind an engine-specific per-object magical property, hidden through some less magical mechanism, or not provided at all (left to the developer to write himself -- slower than the near-max-speed native-code loop in obj_enumerate, but not asymptotically so).

I favor removing __count__ entirely.  If experience from such a change demonstrates use such that we need to support it, we can make it a getter directly on Object.prototype, which would still give people the tool without giving it to them in a way that requires special treatment in the engine.
Comment 1 User image Brendan Eich [:brendan] 2010-03-10 13:11:41 PST
Just remove it. No turd-polishing now that we have ES5 and its (costly but who cares) ways to count properties.

Comment 2 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-03-10 14:27:15 PST
Created attachment 431717 [details] [diff] [review]
Comment 3 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-03-10 14:29:51 PST
Comment on attachment 431717 [details] [diff] [review]

Aw yeah.
Comment 4 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-03-15 15:26:56 PDT
Comment 5 User image Brendan Eich [:brendan] 2010-03-15 15:43:01 PDT

__parent__ next, right?

Comment 6 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-03-15 15:54:35 PDT
Sure, will file another bug for that.
Comment 7 User image :Gavin Sharp [email:] 2010-03-21 01:52:38 PDT
You should probably fix too, to avoid comm-central bustage when this lands on mozilla-central.
Comment 8 User image :Gavin Sharp [email:] 2010-03-21 01:53:35 PDT shows several hits too :(
Comment 9 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-03-31 12:19:04 PDT
I'm fixing the c-c bit once a pul -u completes.

I have a blog post queued up on this topic, just waiting for a TM->m-c merge and a nightly cycle so there's something concrete to point developers toward...
Comment 11 User image Jeff Walden [:Waldo] (remove +bmo to email) 2010-04-06 22:27:51 PDT
Updated this on MDC:

but pretty sure there's more -- crussell on IRC fixed up the property-inheritance template as well.  Other places -- at least the traditional "What's new" document -- still need fixing.

Note You need to log in before you can comment on or make changes to this bug.