Talk:JavaScript/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

__defineSetter__/__defineGetter__

These two functions, used in the article to create private variables, are not in the ECMAScript standard, nor E4X. A quick search didn't bring up any documentation for them, either. They aren't supported by Internet Explorer, so I wouldn't call them a de facto part of the language, either. I'll leave a note in that section. --Quamaretto 02:10, 2 Jun 2005 (UTC) (whoops)

No, they are not part of any standard. They were Mozilla extensions, and (I think) they still work in the newest versions of Netscape, as well as in other implementations that use SpiderMonkey, ie: JavaScript OSA. func(talk) 18:17, 1 Jun 2005 (UTC)

...and Konfabulator, as well. :) func(talk) 23:01, 1 Jun 2005 (UTC)

Hierachies without prototyping?

I don't see the value of this technique or the mention of it. Inheritance is supported directly through prototyping. (Nearly same thing can be done in C, or any other language with function pointers.) Opinions? --Quamaretto 02:09, 2 Jun 2005 (UTC) (whoops)

Yeah, its a bit of an odd example, isn't it? Some things in this article seem almost hostile toward the prototype-based nature of the language. This example:

this.BaseFunction = function()
 {
   alert("Base::BaseFunction()");

where they've used the double colon operator from some class-based languages seems forced and not particularly useful. Of course, the "JavaScript 2.0" people have been moving away from prototyping as well. func(talk) 23:00, 1 Jun 2005 (UTC)

If no one objects, then, I may add some more about prototyping. I've written a few thousand lines of it at work recently (AJAX, for better or worse) and it needs to be explained. --Quamaretto 02:10, 2 Jun 2005 (UTC)

window part of DOM?

The following sentence in the text would lead one to believe that the windows object is part of the W3C DOM:

For example, in a browser, typical host objects belong to the DOM (window, form, links etc.).

That can't be right, can it?

Change it if you want; all common browsers implement a window object in the DOM, and the term DOM commonly refers to any and all of the DOMs, not just w3c. --Quamaretto 29 June 2005 22:15 (UTC)

Confusing example

In the example code following "JavaScript supports inheritance hierarchies through prototyping", all of the names used are what the type of thing is -- the base class is called Base, and so forth. While this is useful as a summary to somebody who already knows how Javascript works, it only confuses me. I'm spending all my brainpower just figuring out what's a reserved word!

I'd suggest either: changing the class/function/variable names to something boring-but-easy-to-distinguish (like the old standby Vehicle, Car, drive(), etc.), or find some way to visually distinguish reserved words (like making them bold).

(Once I've figured out the Javascript object model, I'll gladly try to improve the examples myself, but I don't feel qualified just yet.  :-)

I'll improve it tonight or tomorrow, I promise. But you'll have to remind me. And you'll have to come to my house to do that. :) I'm at work; otherwise I would do it right now. But that stuff is obfuscated and weird; in reality, JS OO can be used just like normal class-based OO. --Quamaretto 29 June 2005 22:12 (UTC)

comments on "usage" section

From the article:

JavaScript embedded in a web browser connects through interfaces called Document Object Model (DOM) to applications, especially to the server side (web servers) and the client side (web browsers) of web applications. Many web sites use client-side JavaScript technology to create powerful dynamic web applications.

This doesn't make much sense (and is quite hard to read, too). JavaScript isn't typically used to connect to web servers (except when using AJAX/XMLHttpRequest techniques). It certainly doesn't connect to the web servers through a document object model. You can't say it connects to "the client side [..] of web applications", as it is a part of a web application, and because the typical use of JS today is not web apps, but small things like those described in the next paragraph of the article.

The author probably wanted to say JS is used in client-side scripting to modify the page through DOM and to send requests to web servers via XMLHttpRequest. That's what the next paragraph is about though, so I'm unsure what to do with this sentence.

It may use unicode and can evaluate regular expressions (introduced in version 1.2 in Netscape Navigator 4 and Internet Explorer 4). JavaScript expressions contained in a string can be evaluated using the eval function.

It should either be moved to the language features section or removed altogether.

Last, AJAX and DHTML are not "design methodologies". I couldn't find a general word for them, but it's more of a "popular technique, using JS+DOM".

--asqueella 23:29, 10 July 2005 (UTC)

Debugging JavaScript code

I changed the intro paragraph in the error handling section. I consider JavaScript debugging nowadays not as difficult as it used to be. It would be nice if somebody else could add some information how the situation is while using Visual Studio or Eclipse. Hirzel 19:56, 24 August 2005 (UTC)

Passing by value Vs. Passing by reference

In the "Functions" section, there is a line that says "Basic data types (strings, integers, ...) are passed by value wheras objects are passed by reference.". I believe this is incorrect - objects like primitive types are passed by value, but it is a reference to the object that is passed. I think this statement should be edited.

Added

The term 'passed by reference' is pretty common and is only misleading if taken out of context. When read together, the meaning of passed by value and passed by reference is as clear as need be.

If further explaination is required, a full explaination should be given on what passed by value and passed by reference mean.

OzFred 00:41, 2 November 2005 (UTC)

My two cents

In JavaScript objectreferences are passed by value. In some languages, like C++ or VB you can have e.g.:

1. ByVal L As Long
2. ByRef L As Long
3. ByVal O As Object
4. ByRef O As Object

in an argumentlist. Numbers 2 and 4 are passed by reference, and assigning a new long integer or object reference will modify this value in the original variable. Numbers 1 and 3 are passed by value and modifying them has no effect outside the function - I believe this to be JavaScript's behaviour. In cases 1 and 2 a long integer is passed, in cases 3 and 4 an object reference; as you can see all four combinations are possible. You cannot pass an argument by reference in JavaScript, although you could emulate it like so:

function refvar(x)
{
  this.val = x;
}

function modifyit(x)
{
  alert(x.val);
  x.val = 42;
  alert(x.val);
}

var myrefvar = new refvar(12);

modifyit(myrefvar);

by noting that although object references are passed by value, their members are passed by reference. Hope this ends all possible confusion (if there was any) for ever. Bye! Shinobu 00:52, 10 November 2005 (UTC)

Additionnal two cents

I agree. In JavaScript, like C and Java, only passes variables by value (even if the specifications say otherwise !). But those variables are either primitives (int, char in C or Java; primitives likes numbers or booleans in JavaScript), or pointers/references to objects (int *, char * in C; Object, Vector in Java; or Array in JavaScript).

Note: In fact, C, Java and JavaScript lack the Visual Basic's ByRef, or the C++ reference operator & (when used in function/method signature, not to be confused by C's use of the & operator to extract the adress of a variable).

If the variable is a primitive, then it appears to be passed as a parameter as with a Visual Basic's ByVal. If the variable is a pointer, then modifying the object by using its methods or properties makes it appear as a VB's ByRef. But should you attribute another "value" to the pointer, then the original object's value is not modified anymore.

For (a JavaScript) example:

function myMain()
{
  var MyArray = new Array() ;
  MyArray[0] = 25 ;
  MyArray[1] = "Hello" ;
  MyArray[2] = null ;

  doSomething(MyArray) ;
}

function doSomething(MyVariable)
{
  MyVariable[0] = 30 ; // in myMain, MyArray[0] becomes 30
  MyVariable = new Array() ; // MyVariable does not point anymore to myMain's MyArray !
  MyVariable[0] = 50 ; // in myMain, MyArray[0] is still 30
}

myMain() ;

Now, there is some confusion, if I am correct here, with the fact that Strings, Numbers etc., are primitive, and in the same time, objects.

Unless I'm wrong, Strings are objects, and are passed by... reference. The subtle difference is that they are immutable, which means that you cannot modify the object's intrinsic value. You can only extract from the original object another object with the modified value:

function myMain()
{
  var strValue = "hello" ;
  doSomething(strValue) ;
  // strValue is still "hello" !
}

function doSomething(p_strValue)
{
  // p_strValue is "hello". In fact, p_strValue and strValue point to the same String object
  p_strValue += " world" ; // p_strValue becomes another String object
  // p_strValue is now "hello world"
  // ...but strValue is still "hello" !
}

myMain() ;

Note that this example works with JavaScript Numbers, Booleans, but not Dates

This kind of subtleties about the distinction of values, references and pointers can be confusing but must be understood to avoid some strange bugs.

--Paercebal 21:58, 21 October 2006 (UTC)

Use of for..in

The text for 'for..in' suggests:

"This loop goes through all enumerable properties of an object (or elements of an array)."

The reference to elements of an array seems to infer that for..in is a suitable method for getting the elements of an array without the added caution that for..in will loop over all enumerable properties. For example, a programmer may overwrite the push() function of Array.prototype.push to ensure that older browsers have it. If for..in is then used on an array, one of the returned properties will be the push() method/function.

Given that arrays are just a special type of object, the parenthesised bit should be dropped and the grammar cleaned up:

"This loops through all enumerable properties of an object."

One excuse for using for..in on an Array is to get the elements of a sparse array without iterating over the entire length. In that case, a normal Object would likely be much more efficient.

public/private

@By default, all members of an object are public. There are no private or protected members (though these can be emulated).: What is meant by the phrase by default here? Consider the following declarations:

var privateVar = 42;
this.publicVar = 42;

"this." isn't even shorter than "var". Better would be to say something like: private members are declared like this, public members like so. Shinobu 00:34, 10 November 2005 (UTC)

Too much

Is this an encyclopaedia entry or is it a Javascript tutorial? This should be cut back by vast amounts.

It's surely not intended as a JavaScript tutorial, but you see, you can't really discuss a programming language without delving into it's syntax. Is this a bad thing? I don't think so - there are a lot of misconceptions about JavaScript (many of those are caused by bad tutorials on the web) and we can eliminate those by presenting a clear picture of the language. I've seen the statement that "JavaScript doesn't support private members" too often to be funny - even on this page before I edited that out. Stating in the article that JavaScript supports private members eliminates this misconception, but you need a code sample to prove your point. Since people can actually see with their own eyes how it works this adds to the credibility of the article. So you want to discuss closures? If you don't mention them, the article fails to mention one of the defining properties of JavaScript. If you do mention them, the shortest and cleanest way to explain the concept is through a code sample. As long as we structure the information in an appropriate way we need not necessarily be afraid that we've got too much of it. Shinobu 02:06, 29 December 2005 (UTC)

Fragmented object discussion

The material about objects is fragmented between the following sections:

3.4 Objects

3.4.1 Creating objects

3.4.2 Constructors

3.7 Functions

3.8 Functions as objects and anonymous functions

Also ugly is that 3.4.2 uses a concept from 3.7. Also in 3.4.1 the new Object() declaration is syntactically the same as using a constructor. I propose a new section hierarchy:

• Objects

  Explain objects as a concept. More JS specifics.

  • Creation

    Simple creation. If you need private members use a constructor (explained later).

• Functions

  Short description

  • Functions as objects
  • Anonymous functions
  • Constructors
  • Etc.

Constructors should mainly be about the fact that you can use private members and that you can execute code on object creation. A problem is that when you talk about objects, you want to have talked about functions before to be able to explain members, but if you talk about functions you want to have talked about objects before since they are objects. Perhaps the objects and functions should be discussed together, introducing concepts in a more pedagogicly appropriate order. Shinobu 01:57, 29 December 2005 (UTC)

Neat, huh?

I think it's kinda neat that the JavaScript interpreter is actually...a web browser!! The Immediate window equivalent is typing something like the following into an address bar:

javascript:alert("Hello World")

I don't know about you, but I think it is cool.

FLaRN2005 23:09, 31 December 2005 (UTC)

By the way, you can download HTML-Kit if you want to experiment. It's great!

Suggestions for this page, Jan 2006

I came to this page for a better explanation of JavaScript and, hopefully, some indication of what the filenames would be on a Windows system. I need to know this as I can't get JavaScript working in Opera and all the Opera and other help files I have read have been useless.

So, perhaps some general info on JavaScript files would be helpful. — Preceding unsigned comment added by 58.104.206.23 (talk) 58.104.206.23

What filenames? The Opera forums are a good place to find Opera-specific help for all purposes.

I don't know if an encylopedic entry is really the place for what you're trying to ask, either.

(Also, sign your message with four tildes.) b0at —Preceding undated comment added 08:34, 2 January 2006 (UTC)

Some dates in the history paragraph, please? When did things happen? Thanks. — Preceding unsigned comment added by 80.55.196.98 (talk) 19:22, 27 February 2006 (UTC)

Separate article for syntax

I propose creating a separate article for the syntax details, along the lines of the C and C syntax articles. The JavaScript article would offer at most a brief summary of the syntax, while the JavaScript syntax article would go into further detail.

I may tackle this myself, sometime soon, but I wanted to raise the notion first. It may require some reworking afterwards to find the right line of separation between the two articles.

Personally, I find a syntactic quick-reference to be of great use, especially when having to work with multiple languages on a regular basis, and I think the information is appropriate for Wikipedia. But ideally, these details shouldn't be in the way of others who don't need them, and they shouldn't weigh down the article as a whole.

--Flash 21:12, 7 January 2006 (UTC)

Javascript or JavaScript?

Mozilla folks call it Javascript. Which capitalization is correct?

"JavaScript" is correct when referring to the original thing as developed by Netscape, but makes it seem to the untrained eye more related to Java than it really is. I think it's okay for the article's title. "Javascript" is good for referring to any given implementation of it, kind of like the differingly-defined but all-encompassing "url". b0at 03:17, 8 January 2006 (UTC)

According to the SAP website: "JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.". Sun refers to it as "JavaScript" (see: Sun Trademarks). For encyclopedic purposes, I think the official Sun version should be used. A mention of alternate spellings could be added to the article. --Flash 05:15, 8 January 2006 (UTC)

Purpose pf JavaScript

Surely the main point of JS is to add functionality to web pages? I find this article too obtuse - some examples should be given to show how JS can be used in web pages, to produce "cool" effects, rather than just examples showing the syntax. Camillus (talk) 18:37, 17 January 2006 (UTC)

I think such demonstrations are more appropriate for the DHTML page. JavaScript was intended mainly to be used in webpages, yes, but it's used for more than that today.

Perhaps an example should be added, though. Are there such 'real-life' examples on other languages' pages? --asqueella 01:56, 18 January 2006 (UTC)

Picture

HTML with JavaScript in a tool that uses colors to help the developer see the function of each piece of code.

This article needs a picture of JavaScript code. I created this one to illustrate what JavaScript looks like, but it was deleted as "useless." It is not meant to be a piece of sample code of use to developers. It is just meant to show people what JS looks like for people who are not developers. --Tysto 18:07, 18 January 2006 (UTC)

I'd be in favour of keeping this image. Rufous 12:56, 19 January 2006 (UTC)

An image is a good idea, but not this one - at least let's have an image which shows whole lines of code, rather than just the first 10 characters! Camillus (talk) 14:12, 19 January 2006 (UTC)

I think we should use this one, until someone creates a better replacement. ~Linuxerist L / T 14:56, 5 April 2006 (UTC)

I don't think that's a good example of Javascript. For starters, it seems most of the picture is HTML. Second, the funky line-wrapping obscures what little Javascript there is. I could argue about the code sample, but I think it would be fine if you just cropped out the beginning of the file and concentrated the picture on the Javascript code. Quamaretto 16:10, 5 April 2006 (UTC)

This image clearly enough shows some of Macromedia's built in JavaScript that Dreamweaver regularly churns out. I agree with the idea, but, seeing a bit more would be good, e.g. some {} braces to show the Java/C/C#-like structure. Therefore it should be someone's own work, that they're prepared to open-licence in the image form, not a picture of something presumably heavily copyrighted by a big corporation. --Nigelj 19:53, 5 April 2006 (UTC)

I suppose I shall go about creating something soon. I have little javascript knowledge, but enough to do this. If I generated the image through Blufish, could I claim ownership? ~Linuxerist L / T 00:14, 6 April 2006 (UTC)

If you do add a picture, could you please a) not use a black background, and b) use SVG? Thanks! 82.139.85.48 15:20, 11 May 2006 (UTC)

I need to work on it, forgot O.o. Anyhow, yes, I will use SVG, but why not a black background? ~Linuxerist E/L/T 03:01, 20 May 2006 (UTC)

I think I posted that when not logged in. The problem with an image with a black (or very dark) background is that the contrast with the surrounding article is too great, resulting in what appears as a stark black block. That way the focus is shifted to the contrast between the image and the rest of the article instead of the appearance of the various elements within the image. You can probably achieve a better effect by using a relatively light background and darker colours (about half intensity perhaps?). Shinobu 09:07, 20 May 2006 (UTC)

JavaScript Guides and References

In order to provide a complete overview about the JavaScript language (and about backwards compatibility of language features that is not always properly specified in later References), it is important to include links to JavaScript Guides that could be considered historic because many of the respective user agents that implement them are no longer supported by their vendors. There have been no JavaScript References before version 1.2, the respective Guides are the reference material instead.

Furthermore, Client-Side JavaScript and Core JavaScript are _not_ the same: the former includes host Netscape-proprietary DOM objects that the latter lacks due DOM standardization efforts. This split took place in JavaScript version 1.4. It is incorrect to refer to something as a "Core Reference for JavaScript version 1.3 (and below)".

The respective links have therefore been re-added and reorganized.

-- PointedEars 14:05, 26 January 2006 (UTC)

There should probably be a critism of section

This article is leaning a bit much on the pro-JS side; and needs a critism section to become more NPOV. Joncnunn 20:26, 17 April 2006 (UTC)

I'm not sure what you mean by pro-JS, or how it would become more NPOV if you added a criticisms section. The major criticisms of Javascript in general are likely to be a lot more POV than the current presentation, unless they come from quoting a well-known outside source. Also, much of the criticism you're looking for may be in Client-side JavaScript. Quamaretto 13:02, 18 April 2006 (UTC)

There are valid criticisms of the language itself and not how it's typically used in client-side scripting. For instance: It lacks classic OO (and opts instead for prototypes). It lacks type checking (and opts instead for duck typing). Most such criticsms are complaints leveled against dynamic languages and prototype-based languages in general, but there are also some other criticisms, e.g. it's syntax is so complex that it's very hard to make a parser for it, or that it lacks a scope operator (and instead anonymous functions have to be used). --Maian 06:36, 15 August 2006 (UTC)

Seems NPOV enough to me 86.142.52.116 09:35, 9 August 2006 (UTC)