[Dormilich]

Recently I had a discussion (in another forum), whether or not Javascript is an OOP language. One side claimed it to be because it uses objects, the other side claimed the opposite because it lacks classes*.

It’s true that you can (similar to PHP) write Javascript code in procedural and OOP style and the protoypal inheritance is something you need to get used to. Still, that doesn’t answer the question Is Javascript truly OOP?




* - there was no agreement, eventually.

[baavgai]

Yes, Javascript is a language perfectly suited to OOP.

First, you have to define what you think Object Oriented Programming is. Then, what elements a language needs to be considered an "OO language." Programmers expect things from OO languages. When they don't get them, they assume the language doesn't meet their personal criteria.

You can use OO techniques in any language ( even C; be afraid ). Encapsulation is usually pretty easy, though things like public/private guards may not be available. I'd say any "duct typed" language will fail someone's OO requirement. One sticking point is inheritance, which loosely typed languages tend to fail on.

I can create an object in JS, with methods, behaviors, attributes, etc. I can't lock things down like in some other languages. Curiously, Python is similar in this and considers itself an OO language. PHP 5 basically wraps an associative array ( like Python ) and claims OO. PHP classes are fugly, but actually have more bells and whistles than Python. There are people who will tell you Lisp is OO...

Javascript doesn't get the level of respect it should. It's a clever language, with a nice object system and higher-order functions. Some very impressive OO frameworks, like jQuery, have been created in it. It's only real fault is that it tends to be learned by beginning programmers who do horrible, rude, public things with it.

[Dormilich]

baavgai, on 31 January 2011 - 03:38 PM, said:

One sticking point is inheritance, which loosely typed languages tend to fail on.

OK, I fail to understand that one.

[forest51690]

I hear that technically Javascript is a "prototyping" language. Whatever that means.

I don't really care whether or not it's really OO. I just know that you can do basic OO in it, which I learned recently For someone who wants to learn Object-Oriented Javascript, I recommend this article.

[baavgai]

Dormilich, on 31 January 2011 - 09:45 AM, said:

baavgai, on 31 January 2011 - 03:38 PM, said:

One sticking point is inheritance, which loosely typed languages tend to fail on.

OK, I fail to understand that one.

What part?

Inheritance, and by extension polymorphism, have meaning in a strongly typed language:

abstract class Pet { abstract void scratch(); }
class Dog : Pet { void scratch() { print "wags tail"; } }
class Cat : Pet { void scratch() { print "purrs"; } }

Pet fido = new Dog();

My code now guarentees a method.

Javascript:

function Pet { this.scratch = function() { }; }

Dog.prototype = new Pet;
Dog.prototype.constructor = function () {
	Dog.call(this);
	this.scratch = function() { print("wags tail"); };
}

var fido = new Dog();

In Javascript, my syntax hasn't ensured a Pet instance. I've gone through the motions, but even at runtime I can't be sure. My attempt at "inheritance" is more attribute overwriting than anything else. As the programmer, I know Dog is related to Pet, but I can't be assured at interpret time, only runtime.

Of course, being able to do things like prototype has it's own advantages...

I don't veer off into a loose vs strong typed thing here. IMHO, interfaces and classes are more necessary for OO in strongly typed languages. In loose languages, it's a different mentality and you can usually fake it.

This post has been edited by baavgai: 31 January 2011 - 10:36 AM

[Dormilich]

baavgai, on 31 January 2011 - 06:35 PM, said:

Javascript:

function Pet { this.scratch = function() { }; }

Dog.prototype = new Pet;
Dog.prototype.constructor = function () {
	Dog.call(this);
	this.scratch = function() { print("wags tail"); };
}

var fido = new Dog();

In Javascript, my syntax hasn't ensured a Pet instance. I've gone through the motions, but even at runtime I can't be sure. My attempt at "inheritance" is more attribute overwriting than anything else. As the programmer, I know Dog is related to Pet, but I can't be assured at interpret time, only runtime.

that does look some kind of, er, complicated. As I know it, you exclude methods from the constructor if possible (memory management).

function Pet() { … }
Pet.prototype.scratch = function () { … };

A more promising approach I found (though not perfect).

// by Gavin Kistner
Function.prototype.extends = function( parentClassOrObject )
{
    if ( parentClassOrObject.constructor == Function )
    {
        //Normal Inheritance
        this.prototype = new parentClassOrObject; // this is the inheritance
        this.prototype.constructor = this; // reset the constructor name
        this.prototype.parent = parentClassOrObject.prototype; // attaching prototype chain
    }
    else
    {
        //Pure Virtual Inheritance
        this.prototype = parentClassOrObject;
        this.prototype.constructor = this;
        this.prototype.parent = parentClassOrObject;
    }
    return this;
}

function Dog() { … }
Dog.extends(Pet);

var fido = new Dog;
fido.scratch();

[baavgai]

Neat.

Dormilich, on 31 January 2011 - 03:41 PM, said:

As I know it, you exclude methods from the constructor if possible (memory management).

It was my understanding that it's usually more a style choice. If anything, the prototype form is slightly more effort for the interpretor.

I did a search, found this:

Quote

In Javascript, each Object can inherit properties from another object, called it's prototype. When evaluating an expression to retrieve a property, Javascript first looks to see if the property is defined directly in the object. If it is not, it then looks at the object's prototype to see if the property is defined there. This continues up the prototype chain until reaching the root prototype. Each object is associated with a prototype which comes from the constructor function from which it is created.
-- http://mckoss.com/jscript/object.htm

Other sources seemed to feel prototype was primarily for extending existing code bases; a constructed object shouldn't be prototyped.

Can't find anything about memory managment. If you can, I'd be interested.

In any case, for Inheritence, I'm still not really seeing it. In spite of some claims to the contrary, that seem to be streatching it.

This post has been edited by baavgai: 31 January 2011 - 05:03 PM

[Dormilich]

anything you write in the constructor (definition) is copied to the created instance, i.e. if you define methods inside the constructor, each copy will hold its own copy of the function statement. if you move the properties to the prototype each of those properties is shared among all instances (may not be very useful for properties*, but method statements are the same for every copy). therefore it is sensible to put only that information in the constructor, which is unique for each instance.


* - technically, there is no difference between a classical method and a classical property in JS since both are objects. hence the need to explicitly test for functions in for…in)

This post has been edited by Dormilich: 01 February 2011 - 12:33 AM

[baavgai]

Ah, I understand the reasoning now; thanks. behavior is highly dependent on how the JS interpretor do the voodoo it do. There might be some that are better than others...

I were creating enough instances that this was a concern, I might reconsider my design. I enjoy JS closures; a lot. I'd hate to prototype them to death in my objects. Good to know, though.

[Dormilich]

if you need something like a priviledged method (a closure of a private variable of the constructor) then you indeed can’t prototype that.

[Dormilich]

baavgai, on 01 February 2011 - 01:20 PM, said:

Ah, I understand the reasoning now; thanks. behavior is highly dependent on how the JS interpretor do the voodoo it do. There might be some that are better than others...

the interpretor doesn’t have much freedom there, as most of the voodoo is defined in the specs. (as I understand it, the interpretors can implement how they do the voodoo (JIT, multi-threading, garbage collection, memory (RAM) management, though most of that is on C/C++-level))

[Lucas Kell]

I personally would say it is not an object oriented language. For me the phrase "object oriented" suggest a predisposition for a language to be used to create an object based structure. Javascript CAN be used in an object oriented fashion, but I don't think its really object oriented as such, just supports some object oriented techniques.

[Dormilich]

Lucas Kell, on 01 February 2011 - 07:34 PM, said:

For me the phrase "object oriented" suggest a predisposition for a language to be used to create an object based structure.

it’s not Javascript’s fault that most coders don’t code object oriented. in fact, pretty much everything in JS is an object.

[barmalei]

I did some work and investigation regarding how OOP can look like in Javascript. There are few basic statements:

• Never use "prototype" property. It is ugly from the point of OOP paradigm (class inheritance basing on an instance of another class !)
  
• Some meta classes should be introduced to make the whole OOP library implementation more graceful

The result:

    var MyClassA = new Class(function($, $$) {
        // declare constructor 
        $(function initialize() { ... });

         // declare several public methods;
         $(function public_method() { ... });
         $(function public_method(a) { ... });
         $(function public_method(a, B)/> { ... });

         // declare public fields 
         $('public_field', 10);

         // declare static method
         $$(function static_method() {...});
    }); 
     
   // declare new class that inherits previous one   
    var MyClassB = new Class(MyClassA, function($, $$) {
        // declare constructor 
        $(function initialize() { ... });
        
        // override method
        $(function public_method(a) { ... });
    }

    // usage
    var a = new MyClassA(), b = new MyClassB();
    a.public_method();
    b.public_method();
    b.instanceOf(A)  // true
    ...

The idea is described on my web site: Graceful implementation OOP in Java Script

This post has been edited by barmalei: 27 March 2011 - 06:27 AM

[Dormilich]

another one not understanding that Javascript doesn’t know the concept of classes …