document.write in the JS reference
Hi there. Please don't change
document.write in the JS reference before first reaching agreement with User:Waldo who switched it to
Reply to Question for your recent JSRef edits
Those moves were a part of my decision to move the documentation of object instances out of constructor pages and over to constructor.prototype. You are right, those properties are not technically properties of the prototype object (according to the spec). This problem also affects more commonly used properties (such as
array.length). However, the reorganization also has these properties set to be moved to constructor.prototype.property and was a factor in the decision to move these.
My sole intention behind these moves was to get rid of the problem of having the pages for the constructor and instances of the constructor mashed together which results in static and non-static properties/methods appearing side-by-side.
There's another thing to consider, and that is that in Mozilla, these properties are properties of the prototype object.
String.prototype.length is initially set to 0 for example. I haven't checked yet, but I'm guessing that properties like this for the prototype object are set to values similar to Java's default values (number types are 0, booleans are false . . .) even though these values are useless since they will be changed during construction. This raises the question, one which I've brought up before, about whether we should be trying to provide a general purpose reference or an in-depth reference that tracks all the inconsistencies between ECMA 262 implementations, which is quite a large task—and not one I'm interested in taking up.
After moving these around (I've almost got them all, I think), I was going to make a mention of this on the pages, that not all properties are "inherited" in the strictest sense. This would include stuff like
length for strings and arrays, these types of properties you've mentioned for
RegExp instances, things like
__noSuchMethod__ for objects, and anything else. This would probably be explained on a separate page (or section) under About and pages in the reference would have a note like "this is a pseudo-inherited property . . . See this page for a better explanation of this."
So what do you think? Should we be doing this differently? Do we need one page to document the constructor, one page to document inherited properties/methods from the prototype, and another page to document the actual instances and properties that are "magically" generated at construction? -- Sevenspade 17:24, 3 January 2008 (PST)
I hadn't considered the conflict with window.print. How would you feel about using
println for these examples instead? If you'd be in favor of this, I'll see what Waldo thinks about it. -- Sevenspade 17:24, 3 January 2008 (PST)
Regarding __parent__ and __proto__
I just moved __parent__ and __proto__ back out. This time, however, I put it directly on the Object.prototype page. It's obvious that I should follow up on my proposal from our previous thread, and I'll probably do it this weekend (probably tonight). Hopefully after adding the appropriate explanations, there will be fewer clashes or hesitancy over where to put these pseudo-properties.
Anyway, I just wanted to bring this up, rather than just undoing those edits with the reason in some hidden away edit summary. -- Sevenspade 11:45, 3 July 2008 (PDT)
Changes to Template:Js_see_prototype
I just made some changes to Template:Js_see_prototype, and it looks like it's broken for the Japanese localization. I tried to change the other localizations to match the English one, but it didn't work. -- Sevenspade
I fixed it, and added URI Encoding function, because $1 may be multibyte string in localization pages. -- Potappo