Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 4 of 4 FirstFirst ... 234
Results 46 to 51 of 51

Thread: OOP JavaScript

  1. #46
    Regular Coder
    Join Date
    Nov 2003
    Location
    Code Heaven
    Posts
    129
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Now,back to the original topic.
    It's quite amazing how JS treats most things as objects,in fact,each data type that can't be defined by the language's standard data types,is treated as an object.
    I would even go to say that everything in JS is an object...(well,umm almost).
    When you see a "string",there you have an object,an array is a data type defined by an object(in fact,in old JS implementations you had to define your own array object,it wasn't implemented by default);
    Everything that has visual impact on the page you handle with objects,even the primitive data types can be viewed as objects - as they have their own wrapper objects.
    Even when writing:
    Code:
    var x=2564;
    you can think of objects ,as x is now a property of the window object.
    This leads to the conclusion that JS is not Object-Oriented,it is object based(as stated in a previous post).
    That's just coz objects have a much greater role than in other languages.
    What were trying to do is emulate some concepts that can be found in OO languages(Polymorphism,Encapsulation,Data hiding,Inheritance ...)
    So,for how many of these can we say that we have an alternative in JS?

    (When you come to think about it,seeing the list of words reserved for future use,it's all clear that we'll be having classes,public,private members and so on...heh,so in any future JS implementation,all this thing about closures would be of no use)
    Last edited by Code Wizard; 04-15-2004 at 11:38 PM.

  2. #47
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    I gather you haven't been sniffing around the ECMA specifications lately? Because there are interesting documents at <http://www.mozilla.org/js/language/>, both the Netscape JavaScript 2.0 specification, the Netscape ECMA-262 4ed proposal (of which both were last updated 2003-06-30), and a link to the ECMA-262 4ed draft, last updated 2003-03-24.

    They are implementing a classical inheritance system. They are also adding typed variables, and a few new native types (Never, Void (what was formerly Undefined), Integer, Type, char; and the machine types sbyte, byte, short, ushort, int, uint, long, ulong, float). It's still backward compatible (though ECMAScript 3 was not forward compatible, so a JS1.5 parser will choke on some rather simple JS2.0)

    Some reserved words are no longer reserved. Some new are added. None of the type names are reserved words, for instance, but they are constants in the global scope.



    They are in other words making ECMAScript 4 more machine close, and closer to C++, further from functional languages. However, behind the scenes, things that are clearly a movement to the functional style are taking place. Primitives are no longer distinguished from compound data types - you can now create members of primitives, which you couldn't in ECMAScript 3. This means a movement towards object orientation, but also a movement towards the functional system of placing more weight in expressions and values, instead of variables and types, an effect standing in contrast to the imperative style. Closures play the same role as they did in ECMAScript 3, but they have taken a less important place as classes have come to take the place constructor functions took before - not that constructor functions are banished, they are just made redundant by the addition of classes to which you may assign custom constructors. They have sadly chosen to build a classical system for inheritance instead of extending the prototyped system of ECMAScript 3, which I would have preferred. Anyway, this means some things - you can now have virtual and final variables, which you couldn't in ECMAScript 3. It also means that classes have a broken (from an ECMAScript 3 POV) delegation system. They inherit at creation moment, and the member lookup is not exactly the same, since in ECMAScript 3 you were guaranteed that there were only a single member with a given name, which you are not in the namespaced and more complicated ECMAScript 4 system.




    Well, enough about a future which is still far away. (Though Mozilla may very well be getting somewhere with JavaScript 2.0 this year, considering how close to complete Epimetheus is.)

    Well, let's have a look at object orientation for a while.

    Inheritance: ECMAScript 3 is pretty clear on this. Inheritance can be done both by aggregation and by dynamic lookup. Closures and a bit of trickery allows us to create public, private and even protected members. And we can create privileged members as well (public members with access to private members). For more information on this, I would recommend not only Douglas Crockford which you all should know by now, but also the a bit more technically correct Jeff Yates. There. That also covers Encapsulation, as that is just what private, public and protected members mean. How about Polymorphism, then? Well, ECMAScript performs implicit type coercion when required, and you may force it usinbg explicit coercion as well. We may not create operators and that means that operator overloading outside what is built in to the native types is prevented, and we may not declare more than one function with the same name. However, we aren't entirely left behind here. We have a dynamic, weakly typed language. That means that though we can't force the type of arguments sent to a function, we may detect them and act thereupon inside the function - the process of code forking. Abstraction is one of the points where functional languages are going strong. JavaScript supports higher order functions and lambda abstractions for control abstraction, and is object based and has an expression based variable handling, which in itself provides some measure of data abstraction. Objects - well, you said it. Everything is an object. It has most criteria for object orientation - and those it doesn't have are those that essentially divides weakly typed languages from strongly typed languages, and dynamic langauges from static - criterions that are very biased towards compiled, imperative languages, because that's their way of data handling.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  3. #48
    Regular Coder
    Join Date
    Nov 2003
    Location
    Code Heaven
    Posts
    129
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Alright...now....my first question in this thread was about uses of OOP in JS.
    The biggest problem I think,is that browsers lack a decent way of storing objects,so they can be used the next time the browser loads the page(this is also reffered to as persistence).
    Of course there are cookies,but this involves a lot(too much,in fact) of string manipulation ,and reconstructing objects,making the whole proces too awkward.
    Also IE has a few other ways of it's own for persisting data,that can be used to a greater extent,but they are far from perfect...
    So,objects concerning JavaScript can be put to use only in the context of the current (browser) session...

    I gather you haven't been sniffing around the ECMA specifications lately?
    True,I'm actually speaking now more from a theoretical point of view,than from what I've learnt in practice.

  4. #49
    New to the CF scene
    Join Date
    Sep 2010
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi I am Hobbes, totally new to posting in these forums. I create web based mmorpg's. I mainly use php and javascript as my main scripting languages. I just wanted to post a little info + a question.

    Regarding: var self = this;

    The only use of this if seen is in this situation:

    Code:
    function foo(){
    
      this.methodA = function(){ 
    
          var self = this;
    
          setTimeout( function(){ self.methodB(); }, 100);
    
      };
    
      this.methodB = function(){
    
        alert('fire');
    
      }; 
    
    }
    
    var someObject = new foo();
    This is the only way that I have found to perform object methods invoked by a timer ( using this.method(); fails since the this keyword is out of scope within the timer ).

    Now I have a question regarding such a use: does "var self = this;" create a duplicate object, doubling the memory usage? If so will "self = null;" at the end of the timer:

    Code:
    setTimeout( function(){ self.methodB(); self = null; }, 100);
    fix this hypothetical issue?
    Last edited by Hobbes; 09-07-2010 at 09:12 AM.

  5. #50
    Senior Coder Dormilich's Avatar
    Join Date
    Jan 2010
    Location
    Behind the Wall
    Posts
    3,135
    Thanks
    12
    Thanked 332 Times in 328 Posts
    this is just a Closure, so there is no "double" object.

    PS.
    PHP Code:
    Function.prototype.bind = function (obj) {
        var 
    fn this;
        return function () {
            return 
    fn.apply(objarguments);
        }
    }; 
    and
    Code:
    // though unnecessary in this example case
    // setTimeout(this.methodB, 100) would suffice
    setTimeout(this.methodB.bind(this), 100);
    Last edited by Dormilich; 09-07-2010 at 10:30 AM.
    The computer is always right. The computer is always right. The computer is always right. Take it from someone who has programmed for over ten years: not once has the computational mechanism of the machine malfunctioned.
    Andrť Behrens, NY Times Software Developer

  6. #51
    New to the CF scene
    Join Date
    Sep 2010
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Interesting indeed


 
Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •