In trying to come up with a basic model to handle all the similar entities for the application domain I'm working on, I created:
A basic object (Entity): that has some shared properties and initializers, setup as Prototype
A product object (Product): that "inherits" from Entity. And contains a list of "Variants"
A variant object (Variant): that "inherits" from Entity.
Product.prototype = new Entity();
Variant.prototype = new Entity();
When I run this, something weird happens: the "variants" list from the "product" object, ends up containing two elements, which is fine, but instead of these being two separates instances of "Variant", they point at the same memory space.
I've done some debugging (alert based), to ensure that, during the 'for loop' that fills the observableArray, things look fine.
var Product = function (data) {
var initial = data || {};
this.variants = ko.observableArray();
this.init(initial);
if (initial.variants != null) {
for (var i = 0; i < initial.variants.length; i++) {
// NOTE: this is the misterious line. Creating two instances
// of 'new Variant', ends up pushing a single instance.
this.variants.push(new Variant(initial.variants[i]));
//-----------------------------------------------------------
alert(this.variants()[i].name());
}
}
I asume I'm missing some Javascript basics to figure out what am I doing wrong.
Heres the complete sample at JsFiddle.
If you put observables on a prototype, then they end up being shared across all instances rather than being their own separate observables. An observable is a function that caches its value internally. So, in this case, every instance has a copy of that same function.
Generally, you would want to avoid putting observables on the prototype, although you can certainly put any other functions (general handlers, subscription callbacks, and computed observable read/write functions).
If you want to create a structure that inherits from another that has observables, then could choose to use one of the various "mix-in" type strategies.
For example, you could apply the base constructor to the sibling object.
var Product = function(data) {
Entity.call(this, data); //call the Entity constructor to add observables, etc.
//do other Product stuff here
};
You can then make the Product prototype equal the Entity prototype or better make the Product prototype have the Entity prototype in its chain like:
Product.prototype = Object.create(Entity.prototype);
If you are supporting older browsers, then look for an Object.create shim.
Updated sample: http://jsfiddle.net/rniemeyer/7AnAz/
Related
In this Udacity video on game development, the instructor mentions that Javascript allows us to create an object by giving a handle to its definition. Then, it says that to allow this "an overloaded object definition will update a hash table with a pointer to its class definition".
I quite know what a hash table, a pointer, an overloaded method, and the factory pattern are, but I cannot make sense of this mysterious statement, or of the rest of the explanation.
"Hash table" is just a fancier way of saying "ordinary Javascript object". What the instructor means by "handle to its definition" is just another way of saying "the function that acts as a constructor for the class".
Ultimately, what he means by the statement you mentioned:
each overloaded entity definition will update a hash table with a pointer to its class definition
is the following:
All "subclasses" of Entity will register their constructor function in a single shared hashmap/object using the key which is the type value.
This allows you to get the constructor function (in other words, the function to call new on, which will return an instance of that entity) for any type by accessing gGameEngine.factory[type].
This is nice, because whenever a programmer adds a new type of entity, so long as they remember to add a new entry to that gGameEngine.factory object with the correct key, then that object will contain everything you need to construct any type of supported object.
So the code that iterates over the JSON structure generated by the level editor can create an instance of any type the same way, using something like:
var typeConstructor = gGameEngine.factory(tileSpec.type),
instance;
if (typeConstructor) {
instance = new(typeConstructor)(tileSpec /* or whatever params */);
}
This is similar to the code visible at around the 1 minute mark of the video you linked to.
Make sense now?
I think all he's saying is that you can map references to functions / objects / variables inside another object. He's using one type of property accessor syntax, but I think he's overcomplicating things by using language like 'handle' and 'hash table'.
var someClass = function () {
// stuff
}
var containingObject = {};
containingObject["someClass"] = someClass;
// same thing as
containingObject.someClass = someClass;
Then you can instantiate the class by calling the containingObject property.
var classInstance = new containingObject["someClass"]()
// or
var classInstance = new containingObject.someClass()
I'm trying to get a better understanding of object oriented patterns in JavaScript. I particulary like the way EmberJS implements their classes with .extend and .create from Parent class Objects.
I've tried to implement a basic version of this on my own, but to no success, my newly instantiated Objects reference the same Object. I.e If I increment a private counter var in instance a via a public method, then separately do the same to instance b, b will reflect both increments.
I was able to achieve a de-referenced object via Object.create(myClass), however this is undesirable as I'd like to achieve this internally and also not rely on client support for that native method.
Here's a jsbin of what I've got: http://jsbin.com/zepaju/6/edit?js,console
Thanks for any help!
This is a pretty big subject, because there isn't a perfect way to make JavaScript work like Java-- you'll always have to invent some new coding idiom, and different people have different preferences.
Looking at your linked code, it's hard to be sure what you're gunning for but it looks like the problem is that you're thinking of an object's prototype as a "class", which is copied into each "instance" (like in Java)-- this isn't the case.
Your create() function is creating each "instance" by doing Object.create(Poll), which makes a new object with the Poll object as its prototype. When you refer to properties of the resulting objects, and those properties are not directly defined on the object, what you get is a reference to a property of the single Poll object.
The fact that you've sealed the Poll object's internal variables within a closure doesn't make any difference to this; the closure variables are hidden from the outside world, but they are accessible to the methods of the Poll object, and those methods are shared between all "instances".
If you want a function that spits out objects with a particular set of methods, and which hide their internal data in a closure, that might look like:
function Poll(challenger,incumbent) {
var challengerVotes=0;
var incumbentVotes=0;
return {
voteForChallenger: function() {challengerVotes++},
voteForIncumbent: function() {incumbentVotes++},
winner: function() {return challengerVotes>incumbentVotes ? challenger : incumbent}
}
}
var poll1 = Poll("Edward","Jacob");
var poll2 = Poll("Vanilla","Stilton");
poll1 and poll2 would not affect one another, and there would be no way to access the vote counts of either except through the supplied methods. I appreciate you're looking for a more generic approach but this is an example of how you might start.
I am receiving an ajax feed of documents that looks something like this (much simplified):
aDocs = [{title:'new doc', ext:'pdf'}, {title:'another', ext:'xlsx'}];
I am going to iterate through the aDocs array and display information about each doc, while adding some methods to each doc that will allow for modifying the HTML for display and making API calls to update the database.
I read here that in order to add methods to existing objects, you can use the __proto__ attribute. Something along the lines of:
function Doc(){}
Doc.prototype.getExt = function(){return this.ext}
Doc.prototype.getTitle = function(){return this.title}
for (var i=0; i<aDocs.length; i++){
aDocs[i].__proto__ = Doc.prototype
}
According to that article above,this isn't official javascript, isn't supported by IE (never will be), and will likely be deprecated in webkit browsers.
Here's an alternative stab at it:
function getExt(){ return this.ext }
function getTitle(){return this.title}
for (var i=0; i<aDocs.length; i++){
aDocs[i].getExt = getExt;
aDocs[i].getTitle = getTitle;
}
Is this second alternative viable and efficient? Or am I re-creating those functions and thereby creating redundant overhead?
Again the above examples are simplified (I know aDocs[i].ext will solve the problem above, but my methods for display and API calls are more complicated).
Is this second alternative viable and efficient?
Yes.
Or am I re-creating those functions and thereby creating redundant overhead?
No, the functions are reused, not re-created. All of the objects will share the single copy of the getExt and getTitle functions. During the call to the functions from (say) aDocs[1], within the call, this will refer to the object the function is attached to. (This only applies if you call it as part of an expression retrieving it from the object, e.g., var title = aDocs[1].getTitle();)
Alternately, if you liked, you could create new objects which shared a prototype, and copy the properties from the aDocs objects to the new objects, but you've asked about assigning new functions to existing objects, so...
Augmenting (adding methods to) the prototype is often the best way to go, but since you're dealing with object literals (or JSON.parse results), you'd have to either augment the Object.prototype which is not done, or create a wrapper constructor, with the methods you need attached to its prototype. The problem will be: getting to grips with this in that case... I'd leave things as they are: use the second approach: a simple loop will do just fine. Besides: prototype methods are (marginally) slower anyway...
The function objects themselves are being created ASAP (if they are defined in the global namespace, they're created as soon as the script is parsed). By simply looping through those objects, and assigning a reference to any function to each object, you're not creating additional functions at all.
Just try this:
var someObj = {name:'someObj'},
anotherObj = {name: 'anotherObj'},
someFunction = function()
{
console.log(this);
};
someObj.func = someFunction;
anotherObj.func = someFunction;
//or, shorter
someObj.func = anotherObj.func = someFunction;
//therefore:
console.log(someObj.func === anotherObj.func);//logs true! there is only 1 function object
someObj.func();//logs {name: 'someObj'}
anotherObj.func();//logs: {name: 'anotherObj'}
There have been posted many questions (and answers) that deal with this matter more in-depth, so if you're interested:
Objects and functions in javascript
Print subclass name instead of 'Class' when using John Resig's JavaScript Class inheritance implementation
What makes my.class.js so fast?
What are the differences between these three patterns of "class" definitions in JavaScript?
Are all more or less related to your question
In this case, I would just pass the object to the constructor of Doc;
function Doc(obj){
this.obj = obj;
}
Doc.prototype.getExt = function(){
return this.obj.ext;
}
Doc.prototype.getTitle = function(){
return this.obj.title;
}
var docs = [];
for (var i=0; i<aDocs.length; i++){
docs.push(new Doc(aDocs[i]));
}
There are two problems with your approach:
You have to copy each method individually for every instance.
Your "class" is not documented anywhere, making it a class makes it clearer that your object has those methods.
Consider the below code.
I created an empty object. And am adding var1,var2,var3 without declaring them.
var har = new Object();
har.var1 = "Var1";
har.var2 = "Var1";
har.var3 = "Var1";
alert( har.var1 );
If I can do this, then why do I need to create a Class and fix the attributes when I can introduce new attributes anytime?
Why would you even need to use objects in the first place? Non-object-oriented languages are already Turing-complete, so everything you can accomplish with objects you can also do without them.
What you're showing in your example is not really an object, but just a dictionary. In cases like this, where you only need to keep several related properties together, anonymous unprototyped objects like the one you're using are the de-facto standard approach (though it is customary to initialize them with the shorthand syntax, e.g. var har = {}). It is an object, since it uses the object data structure, but it is not object-oriented.
Actual objects, in contrast, not only define data, but also the operations that you can perform on that data. Objects have not only properties, but also methods which work on these properties. These properties are usually defined in the object prototype (which you're calling "class", but Javascript is not a class-based language, but a prototype-based one). All methods defined in the prototype are shared between all instances of that prototype.
function Counter() {
this.counter = 0;
}
Counter.prototype.increment = function() {
this.counter++;
alert(this.counter);
}
var c1 = new Counter();
var c2 = new Counter();
c1.increment(); // alerts 1
c1.increment(); // alerts 2
c2.increment(); // independent from c1: alerts 1 again
Each instance is still a dictionary, as in your example (and you can even still add more properties to them, they are not "fixed" by having a constructor and prototype), but now it can also perform tasks on its properties. This can be done your way as well:
c1 = {
counter: 0,
increment: function() {
this.counter++;
alert(this.counter);
}
}
c2 = {
counter: 0,
increment: function() {
this.counter++;
alert(this.counter);
}
}
You can see, however, that if you need two counters, without using prototypes you will need to duplicate your entire object definition. This will be cumbersome to write and maintain, and each increment function will be defined separately, thus it will also waste memory.
That said, in cases where you need an object that you know you'll only ever need one instance of, it makes no sense to define a constructor and a prototype for it. Such objects are usually regarded as namespaces instead of actual objects.
Appendix: Dictionaries vs Objects
A dictionary is a data structure which holds named elements. Besides "dictionary", they are also called associative arrays or hashmaps. Objects in Javascript are implemented as dictionaries — each property is a named element in the dictionary. In addition to a plain dictionary, objects also have a prototype, which is kind-of like a parent object — when you look up a named element in the dictionary and it is not there, it is automatically searched for in the prototype as well. This way, default properties and methods are defined only once in the prototype, and do not need to be copied into each instance. (The prototype of an object is often visible as the instance.__proto__ property, though this is non-standard and deprecated even in browsers that support it; the actual prototype is defined as an internal, non-accessible property by the standard)
So, Javascript objects are actually dictionaries. When you want to use a plain dictionary to store some related properties together, there is no separate syntax in Javascript to create a dictionary that is not an object, so you create an instance of the base Object type to hold your dictionary (it does not matter if you do var dict = new Object or var dict = {}, the result is the same); thus, dictionaries that you use in your code are also objects.
Relatively new to JavaScript, so wondering what is the best approach to achive the below requirement.
I wanted to create JSON object (RPC request object), and need to enforce some structure. As I learn, JS is dynamic language hence I can add any type to an object at any time. But, I like to define a class, which I can populate to construct the JSON request.
var RecReq = {
ID:{},
HeaderLevel:{},
Content:{} //Content object goes here
},
HeaderLevel = {
HeaderID:{},
Note:{}
},
Content = {
Item: [] //Array of Item goes here
},
Item = {
IDs:[]
};
function ReceiveObj() {
this.RecReq = RecReq,
this.HeaderLevel = HeaderLevel,
this.Content = Content,
this.Item = Item
};
return new ReceiveObj();
I am sure many things wrong with the above code. I don't think the object is created with the arrays initialized.
On the returned object, I cannot do push() operation to insert an iten onto Content.
How would you approach this. Do you create an object on the fly, or better to define an object which enforces some structure.
If, as your code suggests, you want your instances to inherit the outer object, one approach would be to assign the prototype of the 'class' (be careful of thinking in class terms in JS - it's not a class in the Java etc sense) to the object.
var obj = {
prop_1: 'foo',
prop_1: 'bar'
}
function Something() {
alert(this.prop_1); //alerts "foo"
}
Something.prototype = obj;
var something = new Something();
This is just one way. There are many patterns for controlling inheritance (and other patterns that would achieve what you want without even going near the concept of inheritance).
As for push() not working, in your code, Content is an object, whereas push() is a method of the Array prototype. In other words, you can push() into an array only. Perhaps you meant Content.Item, which IS an array.
Lastly, I would avoid capitalising names. In JavaScript, this tends to be done only with functions that are used in class simulation (like your ReceiveObj), to denote that they should be instantiated, not merely invoked.