User talk:Sevenspade

Please leave new messages at the bottom of the page. -- Sevenspade 16:19, 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)

JS history

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.
When I first began editing, my initial thought was to completely remove the Backwards Compatibility/JavaScript 1.2 sections, but decided against it after assuming its existence was because including the information was a general desire common among other editors (you all). Instead I opted for keeping a very clear distinction between JavaScript 1.2 information (plus other, older versions) and the documentation (of the modern use) of the language. My thoughts on that were that okay, fine, we can keep the older information about backwards compatibility, but if we're going to do that, it should be comprehensive and not just a few, seemingly out-of-place words on JavaScript 1.2.
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 code tags 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

Re: Inherited properties/methods in JavaScript Reference

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

What are your recent edits based on? Example, in ECMA-262 Edition 3 Specification, RegExp.global, ignoreCase, lastIndex, multiline, source are not properties of RegExp.prototype, but properties of RegExp instances. But, Core JavaScript 1.5 Reference:Global Objects:RegExp:prototype you edited includes these properties... Properties of any global objects can be not always divided into constructor and prototype in ECMA-262 Edition 3 Specification. --Potappo 00:32, 3 January 2008 (PST)

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)

Reply to print revisited

It's good idea. I agree to using println instead of print. --Potappo 04:59, 4 January 2008 (PST)

Moving stuff to Core_JavaScript_1.5_Reference:Global_Objects:String:prototype

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)

I made some samples consider previous posts in mozilla.dev.mdc ML. See "I made a sample of new JS Ref" thread -- Potappo 08:07, 5 February 2008 (PST)
I just took a look at your samples and I think those are fine. I'm new here and I created this account just because I was quite frustrated by the String reference page that suddenly didn't contain the method reference anymore, only to find out that the reference was moved to an obscure page without any descriptive link to it. So I'm talking about quickly making the existing version more usable by either reverting the change or adding links. While I still may find time to engage in a discussion about this on the ML, having a usable reference is my main concern and the changes that were made make things much worse imho. --Jmaurus 10:14, 5 February 2008 (PST)
Reply to Moving stuff to Core_JavaScript_1.5_Reference:Global_Objects:String:prototype --  Sevenspade 16:14, 5 February 2008 (PST)
I agree with Jmaurus - please put things back the way they were. I need to find String methods on the Strings page. Andr3w 07:43, 10 February 2008 (PST)
Reply to Re:Moving stuff to Core_JavaScript_1.5_Reference:Global_Objects:String:prototype -- Sevenspade 10:26, 10 February 2008 (PST)

Template:subpagesSummary formatting

I chose table formatting for Template:subpagesSummary because it is easier to find a statement in a table than in a definition list. —IgorKitsa 17 October 2010

Document Tags and Contributors

Contributors to this page: Nickolay, Ynvich, Sevenspade, Andr3w, Potappo, IgorKitsa, Jmaurus
Last updated by: IgorKitsa,