You moved almost all String methods to the prototype page. While that might be technically correct, there's no pointer in the String documentation that a description of all methods can be found there. I think that makes it unnecessary hard to use the documentation and confuses casual users, especially since the link to the prototype page reads "Allows the addition of properties to a String object." which gives no indication that more documentation can be found at this page.
Also the String object has a box that lists the functions that it inherits from Function.prototype. In my opinion a box of the functions that are inherited from String.prototype should then be added as well, don't you think? --Jmaurus 07:25, 5 February 2008 (PST)
Re: Deletion request
Hi there, just wanted to let you know I answered you at User_talk:Nickolay#Templates_for_non-standard_stuff. --Nickolay 13:32, 2 September 2006 (PDT)
Re the TODO list on your user page - I doubt the information on pre-JS1.5 versions is of any practical interest. After all, JS 1.5 was out for over 6 years now. IIRC someone (brendan?) advocated for removal of pre-1.5 info from the reference.
The ECMA row is helpful as an indicator whether a feature is defined in the standard or a proprietary extension. When we start documenting the JS2 stuff, it may be useful to differentiate ECMA-262 ed. 3 vs ed. 4.
My personal opinion is that NES info is not useful, while information about JS bugs in modern browsers is. --Nickolay 05:10, 5 February 2007 (PST)
- Shortly after I created the TODO, I read over Main's message on the mailing list about the removal of the backwards compatibility sections.
- That's where my plans on expanding "implemented in . . ." boxes came from. Basically, this is my vote in agreement to remove references to deprecated JS versions. I'm aware that you, dria, and Brendan support this, and apparently Maian was fine with it. I will take this to be a "consensus" on the subject and begin making changes when I can.
- Similarly, I am in agreement to remove NES information. Also, I guess my comment about the usefulness of the ECMA line was confusing. I am definitely in favor of keeping information regarding ECMA standardization. However, as of now, pages merely mention "ECMA 262," and do not note which revision of the specification first introduced each aspect. This should be fixed.
--Sevenspade 12:49, 7 February 2007 (PST)
- The difference between ECMA-262 ed.1 and ed.3 is no more interesting than information on JS 1.2 vs 1.5 --Nickolay 06:58, 9 February 2007 (PST)
Reply to (formatting)
- ...you've been changing the Syntax sections' markup from using
codetags to using leading-space preformatted blocks and adding variable declarations, although this isn't the way things are handled in the rest of the reference.
I'm not sure how closely you'd follow my talk page, so I'm responding here. Oh, how I hate the talk-page mechanism...
The leading-space preformatted blocks are cleaner and more readable than the code-formatted ones. The code in effect looks like it's been blockquoted, you don't get misalignment for the first line due to a leading opening code tag (or a gratuitous newline), and on-page it's displayed in a box with a background to distinguish it from article text. The other alternative that I occasionally use is a pre tag, only because HTML (and wiki formatting) in it is interpreted as raw text. As for why it doesn't use the indent-formatting already, that's partly because the initial importer didn't know about it at the time. We were all new to wiki syntax at the time, and we pick it up as we go.
Finally, the code-changing issues. First, let me say the original way the reference did it (e.g. just
propertyIsEnumerable(p)) was completely unacceptable. Even though most methods are almost invariably called on objects, the reference just didn't show them being used that way, making them basically useless. I've been fixing that as I edit pages in the reference. (I'd be surprised if I haven't converted more than half, to be honest.) Second,
var. The reason I've been adding
var is that this code will be copy-pasted a lot. Without
var, any one of these will create a global variable, breaking modularity and eventually setting up whoever's done this for a fall when they depended on the assignment being local. We should not promulgate code with a hidden gotcha like this when it's so trivial to avoid the problem.
I think we should change back the edits you made to undo these changes, but I'd at least like to try to convince you that there are good reasons for the changes before reverting. Let me know your feedback (here or on my page, either works as I read the recent changes feed), and we'll work from whatever your understanding is to some sort of agreement. --Waldo 11:37, 1 December 2007 (PST)
==Re: edit of Error.prototype.filename== withdrawn
I don't think I'll be able to reply you anytime soon, sorry. I suggest asking sheppy about this. --Nickolay 01:02, 14 December 2007 (PST)
Question for your recent JSRef edits
- Reply to Question for your recent JSRef edits -- Sevenspade 17:24, 3 January 2008 (PST)
- Thanks for reply. I understand your idea. You wrote:
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."
- If such explanation is added, I think your recent edits have no problem. --Potappo 04:34, 4 January 2008 (PST)
It's good idea. I agree to using println instead of print. --Potappo 04:59, 4 January 2008 (PST)