 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / September 2006JavaScript for grown-ups
For a computer programmer JavaScript is not difficult. It is pretty easy to look at some code for the first time and figure out what is going on. This is especially true if you have gratuated from an old-fashioned top-down programmer to an object oriented computer programmer. I mean, most Javascript has a look where things are sectioned off into functions. This is pretty much true until one gets into DHTML and a very cool open-source thingy called DYNAPI that is all open source and is all javascript. With DHTML (aka Dynamic HTML) you can do a lot of interesting things which, when run on an IE browser, looks a lot like Flash: http://www.gelsana.com/examples/dynapi.fx.fader.html So naturally I want to experiment with this and figure out how do modify the examples to this. The javascript (.js) file looks like this. http://www.gelsana.com/Flash2.html Some of it is easy to understand but some of it looks like object oriented programming. Does anyone know how all this works or where I can go to find out how it works? I understand that javascript can use functions as objects or classes. But how do I learn how this all works together? For instance, in the copy of the DynAPI javascrpt file you can see this bit of code [code]function DynObject() { this.id = "DynObject"+DynObject._c++; DynObject.all[this.id] = this; }; [/code] Where is .id defined? Is it an element of the DynObject class that is predefined with all javascript classes? Is the same true for the element .all as well? Following this object declaration (if that is what it is) there is this line of code: [code] var p = DynObject.prototype; [/code] Where is .prototype defined? Is it also a predefined element? How is it used? > I understand that javascript can use functions as objects In javascript functions are objects, but that does not seem to be what you are referring to. > or classes. There are no classes in javascript (or there is only one class, depending on how you look at it). When the concept of classes it used in javascript authoring it is a concept applied from outside, when it is useful to do so and only to constructs that satisfy 'class'. > But how do I learn how this all works together? Learning javascript? > For instance, in the copy of the DynAPI javascrpt file you can see this > bit of code > [code] What is this "[code]" stuff about? Are you using a dubious web-based interface to post to a plain-text newsgroup? >function DynObject() { > this.id = "DynObject"+DynObject._c++; > DynObject.all[this.id] = this; > }; > [/code] > Where is .id defined? Right there in the code. When an assignment is made to a named property of an object that property is created on the object if it does not already exist, and the value assigned to it. > Is it an element of the DynObject class that is > predefined with all javascript classes? There are no classes in javascript. Pre-defined properties are inherited through prototypes. > Is the same true for the > element .all as well? The - all - property is a property of the function object, and will be assigned elsewhere in the code. > Following this object declaration (if that is what it is) there is this > line of code: > [code] > var p = DynObject.prototype; > [/code] > Where is .prototype defined? All function objects have - prototype - properties, that refer to an object created and assigned during the creation of the function object (during 'variable instantiation' for a function declaration and during the evaluation of function expressions) (or at least they refer to that object if no other object is assigned to the property). When a function is used as a constructor the value of its - prototype - property is transferred to the created object's internal [[Prototype]] property and then used as the root of the prototype chain when property accessors are resolved against that object. > Is it also a predefined element? The term "element" is usually used to refer to DOM Elements when talking about javascript (because of its primary use in web browsers). It would be confusing to apply the term to the properties of objects in addition. > How is it used? Properties on the - prototype - of a function at the time of creating a new object by using the function as a constructor are inherited by the newly created object. That is prototype based inheritance (as opposed to class-based inheritance which javascript cannot have as it has no classes). Richard. > There are no classes in javascript (or there is only one class, > depending on how you look at it). When the concept of classes it used > in javascript authoring it is a concept applied from outside, when it > is useful to do so and only to constructs that satisfy 'class'. > There are no classes in javascript (or there is only one class, > depending on how you look at it). When the concept of classes it used > in javascript authoring it is a concept applied from outside, when it > is useful to do so and only to constructs that satisfy 'class'. I know that there isn't a keyword "class" in JavaScript yet, but why say there are no classes? function Foo(){} var a = new Foo(); var b = new Foo(); Are "a" and "b" not in the same class (aka group, species, kind) of objects in my script? Where does the damage come from calling Foo the constructor for a class of objects? Peter >> There are no classes in javascript (or there is only >> one class, depending on how you look at it). When the >> concept of classes it used in javascript authoring it >> is a concept applied from outside, when it is useful >> to do so and only to constructs that satisfy 'class'. <snip> > I know that there isn't a keyword "class" in JavaScript > yet, but why say there are no classes? There are no classes. Javascript only has one object type; the dynamic native ECMAScript object. All apparent distinctions between objects follow from augmentations of the native ECMAScript object, but no modification renders that object unmodifiable. > function Foo(){} > [quoted text clipped - 3 lines] > Are "a" and "b" not in the same class (aka group, species, > kind) of objects in my script? That is a runtime state, both can be modified in a way that would make thinning of them as the same 'class' impossible. It can be convenient to think of objects that have undergone like-modifications, are not then going to undergo further modification that would destroy their like-ness and are only going to be used in a particular way, as being of the same 'class', but thinking of them as being of the same distinct 'class' does not make it so. (And that is a set of conditions that can apply to any non-primitive value and the modifications that impose like-ness may be applied in any of many ways.) > Where does the damage come from calling Foo the > constructor for a class of objects? It would promote thinking of javascript as a language that is other than the language that it is. There are always consequences of ding that, mostly disappointed expectations (such as people expecting the - this - value to behave as it would in class-based languages, when in a dynamic language - this - has to be determined at runtime, in the context of its use). When the programmer appreciates that any concept of 'class' employed in designing scripts is applied by the programmer to how the language is being used, and is not something inherent in the language, they can apply the concept to any construct/use that satisfies it. While fixating on constructor/prototype combinations (or any formalised inheritance scheme) as in some way defining 'classes' will be restricting, both in what can be achieved and how it can be conceived. Class-based languages are very far from being dynamic, but being dynamic is what makes javascript so good for browser scripting. Richard. <snip> >There are no classes. Javascript only has one object type; the dynamic >native ECMAScript object. All apparent distinctions between objects >follow from augmentations of the native ECMAScript object, but no >modification renders that object unmodifiable. <snip> I think you go too far when you say this so emphatically. The word "class" is too useful to throw away, and it's a word that has been in use since long before OO languages appeared. How else do you talk about all the objects created by the Date constructor? How else do you talk about all the objects that share the same prototype chain? What javascript doesn't have is "class definitions". In Java, C++, etc, the class definition tells the compiler what data and methods an object has. These can't be altered by the programmer when the program runs. In javascript there are no class definitions and the javascript engine does nothing to stop you changing objects after construction, whether this gives you something very clever or just a terrible mess. On the other hand, it doesn't force you to change them if you don't want to. It's right to be suspicious when the word "class" is used by people coming from a Java or C# background, but wrong to condemn the word outright. John  SignatureJohn Harris > Richard Cornford writes> > [quoted text clipped - 7 lines] > > I think you go too far when you say this so emphatically. How emphatic am I being when I have already said that the concept of 'class' is a useful tool for a programmer to apply to javascript code design and am only insisting that the programmer appreciate that the 'class' concept is not inherent in the language (which it certainly is not) but is something imposed by them on the design? > The word "class" is too useful to throw away, It is, but it should be applied to the right thing. In javascript the concept of 'class' is imposed from outside, and only applicable to a combination of constructs _and_ the way in which they are _used_. > and it's a word that has been in > use since long before OO languages appeared. Let us just stick the OO interpretation of the word. If it is to be relevant to javascript that is the meaning that applies. > How else do you talk about all the objects created by > the Date constructor? How else do you talk about all > the objects that share the same prototype chain? Sharing a prototype chain and/or being an instance resulting from a call to the Date constructor are insufficient in themselves to determine or exclude the appropriateness of the 'class' concept. Consider a parallel with Java, where you want to create a subclass of Date that implement a particular interface that is not currently implemented by Date, and in addition you want a number of other classes to implement that same interface. In javascript you might choose to do that with an object augmenting function. It takes an instance of the original object (a Date object in this instance), adds methods and properties to that object, and returns it. This same function can then be used to add the same interface to any number of other 'classes', and the result is conceptually a sub-class that implements an interface in addition to whatever methods/properties the original had. Now this sub-class (if applied to a Date instance) is also the product of the Date constructor, and shares its prototype with all instances that are products of the Date constructor, but it should not be considered as being of the same class as an instance of Date (it should be considered a sub-class of Date). The class - sub-class relationship suitably parallels similar concepts in Java (for example) but they are the result of how the javascript has been written and used, not an inherent characteristic of objects being employed. > What javascript doesn't have is "class definitions". > In Java, C++, etc, the class definition tells the [quoted text clipped - 6 lines] > other hand, it doesn't force you to change them if you > don't want to. It is partly the fact that it would be unusual to be modifying objects once some sort of concept of being of a particular 'class' has been applied to them that makes employing the concepts in the design appropriate and useful. > It's right to be suspicious when the word "class" is used > by people coming from a Java or C# background, but wrong > to condemn the word outright. And I have never condemned it outright, but I don't think people will learn javascript as a language by fixating on 'classes' as they only come into the picture at the design stage, where the design stage is better executed with a good foundation in the real language being used. Richard. >> Richard Cornford writes> >> [quoted text clipped - 19 lines] >concept of 'class' is imposed from outside, and only applicable to a >combination of constructs _and_ the way in which they are _used_. <snip> This is also what I am saying. If instead of writing "There are no classes." you had qualified it just a little, for instance by saying "There are no declared classes.", then I wouldn't have commented on it. John SignatureJohn Harris |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.