about return statement

[Jack McKalling]

From my definition, prototyping has nothing to do with OOP. It may provide a means to create objects and such, but does this mean it is OOP? As previously mentioned JavaScript saves almost anything as objects. But compared to Java, C#, or even PHP's OOP implementation, JavaScript really isn't object oriented, right?Though it's often proven that some of my definitions are somewhat off to what's usually accepted, and that may apply here too. But it doesn't mean I never have my reasoning. I might seem off or backwards, and you're probably right, but when I mention OOP, I refer to using class definitions and inheritance etc. only, which is a much better way of programming if it were available in JavaScript. Prototyping is different, so this is my reason to say, prototyping, it is weird when you're experienced in "OOP". Am I using a different definition of OOP than you?You do agree with me class definitions are far better than prototyping, don't you? If so, then forget our definition differences as we'd be on the same line after all.It is not so important though, JavaScript doesn't know better, and I just mentioned my worthless opinion there.

[thescientist]

but what I think you're missing is that javascript can be written, through it's prototypal nature, to be OO. There are ways to emulate classes and inheritance, and extending classes, and to make variables and methods private. on a side note, if this conversation about advanced javascript is getting anyone really curious, I would recommend you watch as many Douglas Crockford Javascript videos as you can. Especially the "On Javascript" series.http://developer.yahoo.com/yui/theater/As for definitions, typically people try and keep to them so that when someone says word A, everyone will know with reasonable accuracy what they are talking about. Definitions are just like standards for vocabulary.edit: Personally, I have been using prototyping to emulate class structures a lot recently, and am looking forward to expanding that to inheritance, extending, and privatizing variables and methods. Granted I don't write big time apps like Yahoo, but the conventions are familiar and the organization and clarity of the code speaks for itself.

[justsomeguy]

From my definition, prototyping has nothing to do with OOP. It may provide a means to create objects and such, but does this mean it is OOP? As previously mentioned JavaScript saves almost anything as objects. But compared to Java, C#, or even PHP's OOP implementation, JavaScript really isn't object oriented, right?

Well, yeah, it is. From Wikipedia:

JavaScript is a prototype-based, object-oriented scripting language that is dynamic, weakly typed and has first-class functions.

From the spec:

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.

From my definition, prototyping has nothing to do with OOP.

Prototyping has everything to do with object-oriented programming. It might go by different names in different languages, but you're changing the class definition. Class definitions are pretty fundamental to any object-oriented language. Javascript doesn't have formal class definitions, it has instances instead. That's where prototyping comes into play, you modify the existing base instance directly instead of extending a class definition and then creating a new instance.

You do agree with me class definitions are far better than prototyping, don't you?

Not necessarily, they both have their uses. If one was clearly better, there would be no reason to use the other one. Each has advantages. With classless programming, for example, you can change the prototype and all existing objects of that type immediately get the changes, you don't need to create new ones. You can't do that with inheritance. Many of the Javascript frameworks provide easy ways to extend existing objects in order to create new ones, which is essentially inheritance. Here's my definition for a class that displays statistics for example, notice at the top that my ticket_stats class extends the Panel class, and that certain methods like initComponent, onRender, afterRender, etc extend existing methods so the first thing they do is call the corresponding method in the inherited class to do what they normally do, then the extra stuff this class needs them to do. That sounds pretty object-oriented to me.

TicketSys.widgets.header_widgets.ticket_stats = Ext.extend(Ext.Panel, {  width: 480,  timeoutHandle: false,  refreshInterval: 60, // seconds  techId: 0,  recs: [],  initComponent: function()  {    TicketSys.widgets.header_widgets.ticket_stats.superclass.initComponent.call( this );    Ext.apply(this, {      border: false,      layout: 'vbox',      layoutConfig: {        align: 'stretch'      }    });    this.on('destroy', function()    {      if (this.timeoutHandle)        clearTimeout(this.timeoutHandle);    }, this);  },  onRender: function()  {    TicketSys.widgets.header_widgets.ticket_stats.superclass.onRender.apply(this, arguments);    this.titleBox = this.add({      xtype: 'panel',      height: 16,      border: true,      bodyStyle: 'font-weight: bold; text-align: center; font-variant: small-caps;'    });    this.container = this.add({      border: false,      flex: 1,      layout: 'hbox',      layoutConfig: {        align: 'stretch'      }    });    this.footerContainer = this.add({      xtype: 'panel',      height: 16,      border: false,      layout: 'column',      bodyStyle: 'font-weight: bold;',      defaults: {        xtype: 'panel',        border: true,        style: {          textAlign: 'center',          fontVariant: 'small-caps'        },        columnWidth: .5      },      items: [        {          html: 'Critical Stats',          bodyStyle: 'background-color: #FFFFFF; font-weight: bold;'        },        {          html: 'Historical Stats',          bodyStyle: 'font-weight: bold;'        }      ]    });  },  afterRender: function()  {    TicketSys.widgets.header_widgets.ticket_stats.superclass.afterRender.apply(this, arguments);    this.loadData.call(this);  },  loadData: function()  {    //this.store.load();    Ext.Ajax.request({      params: {page_mode: 'ticket-stats-header-widget', op: 'load-data', tech: this.techId},      scope: this,      callback: function (o, s, r)      {        var resp = TicketSys.main.check_ajax_response(s, r);        if (resp === false) return;                this.titleBox.body.update(resp.title);        if (this.container.items.length == 0)        {          // set up panels          this.recs = resp.data;          this.createBoxes.call(this);        }        else        {          // compare data with cached data to figure out whether to update the store          var update = false;          var highlight_recs = [];          var rec = null, node = null;          for (var i = 0; i < resp.data.length; i++)          {            if (!Ext.isDefined(this.recs[i]) || resp.data[i].label != this.recs[i].label || resp.data[i].value != this.recs[i].value)            {              update = true;              highlight_recs.push(i);            }          }          if (update)          {                        this.recs = resp.data;            // highlight records            for (i = 0; i < highlight_recs.length; i++)            {              node = this.container.items.items[highlight_recs[i]];              node.items.items[0].body.update(this.recs[highlight_recs[i]].value);              node.items.items[1].body.update(this.recs[highlight_recs[i]].label);              node.items.items[0].body.highlight("ffff9c", { duration: 2.5 });            }          }        }      }    });    if (this.timeoutHandle) clearTimeout(this.timeoutHandle);    this.timeoutHandle = setTimeout(this.loadData.createDelegate(this), this.refreshInterval * 1000);  },  createBoxes: function()  {    var pnl = null;    for (var i = 0; i < this.recs.length; i++)    {      pnl = {        xtype: 'panel',        width: 80,        layout: 'anchor',        defaults: {          xtype: 'panel',          border: false        },        items: [          {            anchor: '100% -16',            bodyStyle: 'text-align: center; font-size: 24px; font-weight: bold;',            html: this.recs[i].value          },          {            anchor: '100% 16',            bodyStyle: 'text-align: center;',            html: this.recs[i].label          }        ]      };      this.container.add(pnl);    }    this.container.doLayout();  }});

[Jack McKalling]

So you see, it all comes down to our definition. I never really agreed with wikipedias statement there because I thought OOP was only really a meaningful term if it is distinguised from classless programming (most languages work with objects anyway). This prototyping of JavaScript is quite different from my definition here, and though both methods could have their pros, I think I prefer the latter. But I don't want to start a discussion on which is better, I only need to point out I should have phrased myself from the start. Like this:Programmers who are (only) used to define classes like in e.g. C# or Java, will probably find the prototyping syntax of JavaScripts' OOP kind of weird. They are used to know what type every object is, more so because of the strongly-typed languages, rather than modifying the type from an instance pointer.Man I really hate explaining myself, I don't know why I'm so different.</OOP_subject>Aside from this advanced subject, I hope the return statement has become more clear to you now, newrehmi. Feel free to come back if needed.

[justsomeguy]

I never really agreed with wikipedias statement there because I thought OOP was only really a meaningful term if it is distinguised from classless programming

That's not the classical definition, classless programming is a subset of OOP ("classless" has no meaning outside of the context of objects). OOP is a very broad term, I don't think it's as specific as you think it is. I'm also not aware of a language that uses objects which isn't considered object-oriented. If a programming language uses objects, then you can also create objects or classes, and it's object-oriented. I haven't heard of a language where you can use objects but you can't create your own.Anyway, like I said, OOP is a very broad term and covers a wide range of languages. It's difficult to precisely define or list a set of features that must be present for a language to be considered object-oriented, but there's a description about that here:http://en.wikipedia.org/wiki/Object-orient...ts_and_featuresYou're welcome to define OOP however you want, but you shouldn't go around claiming that Javascript is not OOP. Javascript and prototype-based programming are a subset of OOP, just like class-based programming is also a subset. It's not correct to equate all of OOP with class-based programming specifically.

most languages work with objects anyway

You're only saying that because this is after the 90s, and most of the languages that you've worked with are OOP languages. That wasn't true before 1990.

[jeffman]

True. MacOS did not support native OOP till very late in the 90s. You needed library support for that. A typical Mac API function might require seven arguments or so, one of which might be a bitmap, and 2 others might be pointers. Blecch.

[newrehmi]

Aside from this advanced subject, I hope the return statement has become more clear to you now, newrehmi. Feel free to come back if needed.

yeah thanks guys... watching all this discussion has echoing so much knowledge and understanding that I still lack, although i didn't really understand a thing. However about the return statement, avoiding global and anonymous function, i will need to do more example, more test and more project to get a real grasp in it, as like what albert einstain said, the only source of knowledge is experience. I ll ask anything later, because I think now I need to digest all this thing first >.<' thanks jack, mage, scientist, deirde's dad and all the others trying to help.

[thescientist]

Aside from this advanced subject, I hope the return statement has become more clear to you now, newrehmi. Feel free to come back if needed.

yeah thanks guys... watching all this discussion has echoing so much knowledge and understanding that I still lack, although i didn't really understand a thing. However about the return statement, avoiding global and anonymous function, i will need to do more example, more test and more project to get a real grasp in it, as like what albert einstain said, the only source of knowledge is experience. I ll ask anything later, because I think now I need to digest all this thing first >.<' thanks jack, mage, scientist, deirde's dad and all the others trying to help.

yes you do want to avoid globals, but you do want to use anonymous functions. It's actually one of the highlights of the language.