Reference

Inheritance and Private Variables

The guide section links to an interesting document discussing how to create and use private variables in objects, which is great if you want to protect the various properties within an object from being poked at accidentally. I also just read a document on proper inheritance using apply(). Well if you combine the two, you can have inherited private variables:

function MyClass(){
    var property = 5;
    this.tellMe = function(){ return property; }
}

function MyOtherClass(){
    MyClass.apply( this );
}

var o = new MyOtherClass;
alert( o.tellMe() ); //alerts 5 as you'd expect

— the preceding comment was added by Psygnisfive (talk – contribs) on 22:23, 4 December 2006

Terminology

We need a terminology appendix. For example, "script" and "program" are synonymous. So are "current object" and "context object". We could also put in layman definitions there for JS constructs like functions and variables. --Maian 01:43, 30 September 2005 (PDT)

We should define the terms we are using. In particular this means we should define activation object somewhere (and link to it whenever we mention it). --Nickolay 18:40, 16 July 2006 (PDT)

JS 1.2 and Gecko 1.8

Per the fix for bug 255895, "JavaScript1.2" values for the script's language attribute no longer work, e.g. <script language="JavaScript1.2"> will execute the script in the latest JS version rather than JS 1.2.

So how should this be documented? In Fx 1.0, JS 1.2 is available, but not in the upcoming Fx 1.5. There are 5 cases where "JavaScript1.2" is mentioned in this reference: Special:Search?search=JavaScript1.2&go=Go. How should they be revised?

--Maian 23:43, 21 September 2005 (PDT)

I think we need a new section in the reference that specifies the differences between versions, collecting this information into a single location rather than leaving it scattered haphazardly throughout the reference as it currently is. Once that is done, the various code samples should be updated to reflect current practices and code if they cannot be written in a "version-neutral" manner. Do you think this makes sense? -- dria 04:27, 22 September 2005 (PDT)

Those examples are not "bad examples" per se. They are there specifically to show the differences between the two versions. I was wondering what should be done about those examples, since they would no longer be valid with Fx 1.5+ and family. BTW, https://bugzilla.mozilla.org/attachment.cgi?id=195375 is a screenshot of a table of differences. --Maian 05:10, 22 September 2005 (PDT)

If the examples are there specifically to show the differences between two versions of JS, and if we have a section in the reference that is dedicated to discussing these differences, I would think that those samples should be included in that section of the reference. Or am I misunderstanding something? -- dria 05:30, 22 September 2005 (PDT)

The examples (or most of them at least) say that the browser can use the JS 1.2 engine with the language="JavaScript1.2" tag, but this is no longer possible; language="JavaScript1.x" tags will always use the current version now, i.e. JS 1.6. So while the examples do show what JS 1.2 does, they incorrectly indicate that it's possible to switch to the 1.2 engine. --Maian 05:41, 22 September 2005 (PDT)

This is true. The wording should be changed with the Javascript 1.x examples, as well as refer to the versions in the past tense. I also support the use of a deprecated pre box with these examples. Since it's been 9 months since the last comment on this, I think I'll go ahead and change all of the examples. If anyone disagrees, you can always revert. Sevenspade 13:19, 2 July 2006 (PDT)

After some thought, I removed the references to using LANGUAGE="JavaScript1.2", and all references are merely presented as information detailing past behavior. The "Backwards compatibility" sections have been renamed to "Behavior in older versions." However, I think this is only appropriate if we are going to document the evolution of everything, or at least note the most significant changes introduced in the various versions.

Otherwise, I think we should just remove the "Behavior in other versions" sections, and rename the "JavaScript 1.2" section headings to something like "Differences with JavaScript 1.2," as well as include a link to the yet-to-be-written JavaScript 1.2 page documenting the various oddities and deviations made in that version, something which I think we should do anyway. Maybe something like Main Article: JavaScript 1.2--Sevenspade 15:16, 6 July 2006 (PDT)

As a side note, the ability to to specify different versions has come up again - now between versions 1.6 and 1.7. With <script type="application/javascript;version=1.7" />. See New_in_JavaScript_1.7#Using_JavaScript_1.7. This will impact the presentation of future examples if it hasn't already. --George3 11:47, 14 Sept 2006 (EDT)

SGML comment hiding quirks

SGML comment hiding needs to be mentioned here and its consequences. Brendan just mentioned one obscure one here: https://bugzilla.mozilla.org/show_bu...?id=310993#c20 --Maian 22:46, 5 October 2005 (PDT)

Section title capitalization

There's an inconsistency in the capitalization of section titles. Some capitalize everything as if it's a book title. Others just capitalize the first word. Which scheme should we take, or does it even matter? --Maian 07:11, 8 September 2005 (PDT)

If you want to make them consistent, I think we should go with the "First word only" capitalization, rather than the book-title style. Thanks :) -- dria

deprecated pre box

Is there any wiki markup available for deprecated examples?

--Maian 20:24, 25 Aug 2005 (PDT)

Help:Custom_Templates#Template:deprecated_header --Nickolay 00:58, 26 Aug 2005 (PDT)

Hmm, that was a bad question. What I meant to ask is: what markup should I use for bad examples (which aren't necessarily deprecated), i.e. examples that show what not to do? --Maian 02:07, 26 Aug 2005 (PDT)

Oh, I don't think so, but you can ask dria to create a CSS class for that. --Nickolay 11:50, 26 Aug 2005 (PDT)

I'll add it to my TODO list for the new skins. I have to go through them again this weekend to fix up some stuff anyhow. Good idea, Maian. Thanks :) -- dria 21:06, 26 Aug 2005 (PDT)

coding style

Should semicolons be added to all the examples?

--Maian 21:06, 25 Aug 2005 (PDT)

The original authors didn't use semicolons, but I'd add them. --Nickolay 00:58, 26 Aug 2005 (PDT)

(More coding style questions) --Maian 04:06, 31 Aug 2005 (PDT)

I'd say, just make a note here about decisions you make. It would be best to have all examples to use the same style. --Nickolay 05:37, 31 Aug 2005 (PDT)

Gonna follow Mozilla's coding guides here: http://www.mozilla.org/hacking/mozil...de.html#Visual --Maian 00:30, 20 September 2005 (PDT)

btoa() and atob() base64 encode and decode functions

This documentation is missing the base64 encode (btoa) and decode (atob) functions. Anyone know why this has been left out?

Danbeck 07:02, 22 September 2005 (PDT)

AFAICT , base64-related functionality is not a part of the JavaScript engine, but a DOM feature (probably non-standard). --Nickolay 08:31, 22 September 2005 (PDT)

What's funny is that this Talk page shows up first in a Google search for "btoa javascript". This is number 2. It's not in the ECMA docs. If it's not in a standard, and that Sun doc is corrent, then it should probably go in the window object methods. --Jonnyq

I've already added those methods in the methods listing, but I haven't defined them yet. --Maian 02:39, 21 October 2005 (PDT)

delete?

I don't see any mention in the operators section for the delete operator. Did this operator get removed/deprecated, or is it missing from the documentation?

Brundlefly 13:15, 19 December 2005 (PST)

Neither: Core JavaScript 1.5 Reference:Operators:Special Operators:delete Operator --Nickolay 14:48, 19 December 2005 (PST)

reading offline?

Well, may be it's no so common in today's world... but is there a way to get content of jsref-1.5 or other documents as a tarball? There are still valid needs for this: computers on slow links, computers behind insane firewalls, as well as computers not connected to internet.

Unfortunately there is not an [easy] method to download content/packages of content off of DevMo for 'local' browsing/viewing/printing, yet. It is in the "Nice to have" Category for us here, however I am unaware of anyone feverishly working on it. (There are some other priorities ahead of that, imho). If downloading the stuff is your priority you are free to field ideas/concept to the DevMo Mailing List for discussion, and then actually code it (or find someone to do so). Thanks for your thoughts --Callek 15:05, 13 January 2006 (PST)

Notification when reorganization is finished

Leandro (localiser for the Portuguese wiki) would like to be emailed when the JS Reference reorganization has been finished. His user page is here: http://developer.mozilla.org/pt/docs...%C3%AAs_Xavier

-- dria 08:19, 24 February 2006 (PST)

Object and Function Relation

here is my problem , it has been breaking my head for quite some time now. i'm very confused about the way Function and Object in the JavaScript core are related

at first i thought it was something like this :

Function -> Object -> instance

instance is for example the Math Object, it behaves same way as creating new Object.

i checked this by doing

alert(Math.constructor)			//shows that Object is its constructor
alert(Object.constructor)			//shows that Function is its constructor
alert(Function.constructor)		//shows that Function is its constructor

note : the Function.constructor seems to keep on refering to itself, if you do the following you get same results
which suggests that this is indeed the top level object.

alert(Function.constructor.constructor)
alert(Function.constructor.constructor.constructor.constructor)

Function == Object

However the following statement suggests that Function IS Object.
But when we create a prototype method for Object its also available in Function

Object.prototype.myfunction = function() {};
alert(Object.myfunction);		//available in Object
alert(Function.myfunction);		//available in Function

also the opposite is correct, when we create a prototype method for Function it is available in Object

Function.prototype.myfunction = function() {};
alert(Object.myfunction);		//available in Object
alert(Function.myfunction);		//available in Function

So no matter what we prototype Function or Object , it will be available in both... <p>So all this now suggests that Function IS Object.

Note that instances derived from function/object also have this function when doing this.

alert(Array.myfunction);		//available in Array

(Array cannot be prototyped)

Object -> Function -> instance

But there is another but...

now if we create a prototype for Object , and create instances of Function and Object we still see that the functions are still available in both instances. which still suggests that Function IS Object

Object.prototype.myfunction = function() {};
o = new Function();
alert(o.myfunction);		//available in Function
o = new Object();
alert(o.myfunction);		//available in Object

But the following statement is again quite shocking to all the above
if we create a prototype method for Function , and create instances of Function and Object it shows that the method is only available in Function.

Function.prototype.myfunction = function() {};
o = new Function();
alert(o.myfunction);		//available in Function
o = new Object();
alert(o.myfunction);		//not available in Object

which again suggests that Object IS NOT function. wich means that Object actually doesn't inherit from Function , but Function inherits from Object which is exactly the oppisite as my first thought (see picture above).
i say this because now the function is not available in object, as if the inheritance is :
Object->Function->instance

but... while also holding in account the previous example where it was avalable in both instances when prototyping Object it should be :
Function->Object->instance
or
(Function=Object)->instance

and ofcourse Function == Object return false ;) and the following statements also tells me that Function == Object although Math is only an instance of Object... which basicly says Function != Object

alert(Function instanceof Object)		//true
alert(Object instanceof Function)		//true
alert(Math instanceof Object)			//true
alert(Math instanceof Function)			//false

note that the Methods and properties for Object in this reference are also available for Function and vice versa ...

Actual Question

so my question is , what the heck is going on here ...

IS Function same as Object. is Function an instance of Object or is Object an instace of Function ?

note that the Methods and properties for Object in this reference are also available for Function and vice versa ...

--Aaike82 18:54, 18 August 2006 (PDT)

Actual Answer: Object > (Function, everything else). Everything in JavaScript is descended from Object, including functions. All functions in JavaScript (that is, every object that has an internal [[Call]] or [[Construct]] property) are functions as well as objects (including the Function object itself). The reason Object instanceof Function evaluates to true is because Object can be used as a constructor function. A subset of the "Object > (Function, everything else)" chain could be Object > Function > (Object, Function, Array, String, Boolean, Number, Date, RegExp, Error). Array, for example, as a constructor function is an instance of the Function object, which happens to be an instance of Object; therefore, Array is also an instance of Object. This makes sense. The confusion sets in when you consider that Object is also a constructor function, therefore an instance of Function, and, furthermore, an instance of Object; this is where the recursion is introduced, and why you can infinitely do

Function.constructor;                                                        //Function
Function.constructor.constructor;                                            //Function
. . .
Function.constructor.constructor.constructor.constructor.constructor . . . ; //Function

Note that Math is not a constructor function, but merely a global object with methods and properties useful to perform various mathematical operations. This is why Math instanceof Object evaluates to true, but Math instanceof Function does not. Compare this to the Date object. Like Math, Date is a global object that contains useful methods (Date.parse() and Date.UTC()). In addition to this, however, Date is also a constructor function: it constructs objects of the class Date, and thus is an instance of both Object and Function, whereas Math is merely an instanceof Object. --Sevenspade 14:23, 17 January 2007 (PST)

New JavaScript features, such as "for each...in"

This page doesn't mention Core_JavaScript_1.5_Reference:Statements:for_each...in. The for each...in loop should either be listed on this page or moved to a different category. And somebody should see if there are other features in the same situation. HeroreV 00:49, 27 October 2006 (PDT)

Since the for each...in loop is a 1.6 feature (not a 1.5 feature), maybe someone should rename this page/category to be either a general JavaScript Reference or update it to be the 1.6 Reference. Having 1.6 features defined in the 1.5 reference might be confusing. cstevens 10:23, 20 December 2006 (PST)

We do plan to move the pages around, see Core JavaScript 1.5 Reference/reorg, but it's not clear when that will happen. In the meantime, newer features from JS 1.6 (and hopefully someone will add JS 1.7 features too) are being added to the reference with appropriate version information on the page itself. Yes, it can be slightly confusing, but it's better than no documentation for newer features at all. --Nickolay 01:53, 22 December 2006 (PST)

Yes, seeing stuff that doesn't apply to 1.5 on a page titled "... JavaScript 1.5" might be a little confusing. But there is no other place to put JavaScript 1.6 features at the moment. (There is no "Core JavaScript 1.6 Reference" yet.)

What should we do, that will be the most useful to our readers?

• Copy all the "... JavaScript 1.5 ..." pages to "... JavaScript 1.6 ..." ? Then carefully update all links to the JavaScript 1.5 pages to link to the JavaScript 1.6 pages -- unless the links are specifically about JavaScript 1.5 ? Then do it all over again when JavaScript 1.7, JavaScript 2.0, JavaScript XXXXII.1, etc. comes out ?
• Make a footnote on each page, pointing to a page listing "Hot New JavaScript Features", which in turn points to 1 page for 1.6, 1 page for 1.7, etc., listing all the differences from one version to the next ? This would be the simplest thing for us to write. But someone trying write some JavaScript 2.0, wanting a list of all the features it supports, might be annoyed at having to read through *all* the updates.
• Make a footnote on each page, pointing to a page listing "Hot New JavaScript Features", which lists all the differences between the current latest version, and the documented 1.5 version ? (Every time a new version comes out, a few more things are added to that page).

None of those options appeal to me. What is the Right Way to write about the latest JavaScript version? --DavidCary 06:42, 31 January 2007 (PST)

We already discussed this. See Core JavaScript 1.5 Reference/reorg. The Right Thing to Do seems to be:

• Move all the "... JavaScript 1.5 ..." pages to "... JS ..." (no version number). Make the pages document the latest version. Each statement/function/object/operator/feature has a small note telling what version introduced that feature. Perhaps a larger footnote if there are backwards-compatibility issues involved in using that feature.

XMLHttpRequest

XMLHttpRequest is a host object provided by the browser, not part of JS core language. I reverted the addition of XHR to the reference. We should link to some DOM vs. JS article from the main page and global objects page at least. --Nickolay 09:48, 31 January 2007 (PST)

Yes, it's not a "core" JavaScript object. Let me try to add the links you suggested ... --DavidCary 10:25, 31 January 2007 (PST)

Why distinguish global objects from global properties from global functions?

Why do we distinguish global objects from global properties from global functions? It seems like "global object" and "global property" are synonyms, and all global functions are global objects/properties. Is there something I'm missing? Ruakh 20:31, 26 February 2007 (PST)

This was something that was supposed to be fixed in the reorganization, which has still yet to occur. Sevenspade 22:34, 26 February 2007 (PST)

Since it doesn't look like the reorganization is going to happen in the very near future, is there any reason I shouldn't take care of this now? Ruakh 14:40, 27 February 2007 (PST)

Please don't start making large changes without getting an OK from dev-mdc. What did you have in mind?

FWIW, I brought up the topic of jsref reorg again recently .

IMO, it's useful to have separates lists for global functions, global constructors, and other global properties on the contents page.--Nickolay 19:10, 7 March 2007 (PST)