Closed
Bug 551529
Opened 15 years ago
Closed 15 years ago
Remove __count__
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla1.9.3a4
People
(Reporter: Waldo, Assigned: Waldo)
References
Details
(Keywords: dev-doc-complete, Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
(deleted),
patch
|
shaver
:
review+
|
Details | Diff | Splinter Review |
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•15 years ago
|
||
Just remove it. No turd-polishing now that we have ES5 and its (costly but who cares) ways to count properties.
/be
Summary: Make __count__ non-special, either by removing it or by making it a getter on Object.prototype → Remove __count__
Assignee | ||
Comment 2•15 years ago
|
||
Attachment #431717 -
Flags: review?(shaver)
Comment on attachment 431717 [details] [diff] [review]
KILL THEM
Aw yeah.
Attachment #431717 -
Flags: review?(shaver) → review+
Assignee | ||
Comment 4•15 years ago
|
||
Status: NEW → ASSIGNED
Whiteboard: fixed-in-tracemonkey
Target Milestone: --- → mozilla1.9.3a4
Comment 5•15 years ago
|
||
Great.
__parent__ next, right?
/be
Assignee | ||
Comment 6•15 years ago
|
||
Sure, will file another bug for that.
Comment 7•15 years ago
|
||
You should probably fix http://mxr.mozilla.org/comm-central/source/suite/browser/test/browser/browser_pluginnotification.js too, to avoid comm-central bustage when this lands on mozilla-central.
Comment 8•15 years ago
|
||
https://mxr.mozilla.org/addons/search?string=__count__ shows several hits too :(
Keywords: dev-doc-needed
Assignee | ||
Comment 9•15 years ago
|
||
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...
Assignee | ||
Comment 10•15 years ago
|
||
Assignee | ||
Comment 11•15 years ago
|
||
Updated this on MDC:
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Object/prototype#section_3
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.
Comment 12•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•