User talk:Potappo

document.write in the JS reference

Hi there. Please don't change print to document.write in the JS reference before first reaching agreement with User:Waldo who switched it to print. There is a reason to avoid browser-specific APIs - JS is widely used outside of browsers too. --Nickolay 09:18, 15 March 2007 (PDT)

Oh,sorry. But, print conflicts with window.print. So, I think that print should be changed to othrer function name. --Potappo 17:23, 15 March 2007 (PDT)

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 string.length and array.length). However, the reorganization also has these properties set to be moved to 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 __proto__ and __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)

Reply to print revisited --Potappo 05:05, 4 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


Document Tags and Contributors

 Contributors to this page: Potappo, Sevenspade, Nickolay
 Last updated by: Potappo,