I'm trying to figure it out which one is the best way to reuse code, I'm reading about Module Pattern and Prototype Inheritance Pattern, seems like Modules are the hot stuff these days, so I made a little example about how to implement this thing, but seems like is a little bit complicated, at least isn't easy as Prototype Inheritance, what do you guys think about these?.
About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay (http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, I don't know if is some performance/bad practice issue when I add "extend" method to Function object.
On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez
> I'm trying to figure it out which one is the best way to reuse code, I'm > reading about Module Pattern and Prototype Inheritance Pattern, seems like > Modules are the hot stuff these days, so I made a little example about how > to implement this thing, but seems like is a little bit complicated, at > least isn't easy as Prototype Inheritance, what do you guys think about > these?.
The way I've internalised this (and I'm not sure if it's correct, please feel free to jump in)
* The module pattern creates multiple instances of functions instead of using the prototype chain, thus consuming more memory when instances of it are created using the "new" function.
* The module pattern is good for creating "singletons" though.
* The module pattern is good for namespacing code (i.e. use it to wrap your "class" definition that gets instanced, this is somewhat similar to how I use CommonJS modules)
nebi...@gmail.com> wrote: > About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay ( > http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, > I don't know if is some performance/bad practice issue when I add "extend" > method to Function object.
> On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez > Saldarriaga wrote:
>> Hi! :),
>> I'm trying to figure it out which one is the best way to reuse code, I'm >> reading about Module Pattern and Prototype Inheritance Pattern, seems like >> Modules are the hot stuff these days, so I made a little example about how >> to implement this thing, but seems like is a little bit complicated, at >> least isn't easy as Prototype Inheritance, what do you guys think about >> these?.
var MODULE_TWO = (function (old) { var my = {}, key;
for (key in old) { if (old.hasOwnProperty(key)) { my[key] = old[key];
} }
var super_moduleMethod = old.moduleMethod; my.moduleMethod = function () { // override method on the clone, access to super through super_moduleMethod
};
return my;
}(MODULE));
About the memory use, yes, some of the articles below say that, but I think for the reuse code approach isn't matter, at least if you have a really large code base. Maybe the prototype chain approach it's better, but what about multiple inheritance?. I was looking how Google Closure (http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) do this and I came up with this: http://jsfiddle.net/n98dq/
var App = App || {};
App.Util = (function ($) { var module = {};
function inherits(child, parent) { function I(){}; I.prototype = parent.prototype; child.prototype = new I; child.prototype.constructor = child; }
module.inherits = inherits;
return module;
}(window.jQuery));
function A() {} A.prototype.bark = function () { console.log("A:bark");
};
function B() {}
App.Util.inherits(B, A);
var b = new B(); // inspect. console.log(b); // bark!. b.bark();
-- Juan Felipe Alvarez Saldarriaga http://juan.im Twitter: @nebiros GTalk: nebi...@gmail.com Skype: jfasaldarriaga
On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote: > The way I've internalised this (and I'm not sure if it's correct, please feel free to jump in)
> * The module pattern creates multiple instances of functions instead of using the prototype chain, thus consuming more memory when instances of it are created using the "new" function.
> * The module pattern is good for creating "singletons" though.
> * The module pattern is good for namespacing code (i.e. use it to wrap your "class" definition that gets instanced, this is somewhat similar to how I use CommonJS modules) > Samuel Richardson > www.richardson.co.nz (http://www.richardson.co.nz) | 0405 472 748
> On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay (http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, I don't know if is some performance/bad practice issue when I add "extend" method to Function object.
> > On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez Saldarriaga wrote: > > > Hi! :),
> > > I'm trying to figure it out which one is the best way to reuse code, I'm reading about Module Pattern and Prototype Inheritance Pattern, seems like Modules are the hot stuff these days, so I made a little example about how to implement this thing, but seems like is a little bit complicated, at least isn't easy as Prototype Inheritance, what do you guys think about these?.
why not just use the closure goog.inherits function then. For memory to become an issue you don't need a large code base, you need many instances or a low powered device.
On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga <
> var MODULE_TWO = (function (old) { > var my = {}, key; > for (key in old) { > if (old.hasOwnProperty(key)) { > my[key] = old[key]; > } > } > var super_moduleMethod = old.moduleMethod; > my.moduleMethod = function () { > // override method on the clone, access to super through super_moduleMethod > }; > return my; > }(MODULE));
> About the memory use, yes, some of the articles below say that, but I > think for the reuse code approach isn't matter, at least if you have a > really large code base. Maybe the prototype chain approach it's better, but > what about multiple inheritance?. I was looking how Google Closure ( > http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) > do this and I came up with this: http://jsfiddle.net/n98dq/
> var App = App || {};
> App.Util = (function ($) { > var module = {};
> function inherits(child, parent) { > function I(){}; > I.prototype = parent.prototype; > child.prototype = new I; > child.prototype.constructor = child; > }
> module.inherits = inherits;
> return module; > }(window.jQuery));
> function A() {} > A.prototype.bark = function () { > console.log("A:bark"); > };
> function B() {}
> App.Util.inherits(B, A);
> var b = new B(); > // inspect. > console.log(b); > // bark!. > b.bark();
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
> The way I've internalised this (and I'm not sure if it's correct, please > feel free to jump in)
> * The module pattern creates multiple instances of functions instead of > using the prototype chain, thus consuming more memory when instances of it > are created using the "new" function.
> * The module pattern is good for creating "singletons" though.
> * The module pattern is good for namespacing code (i.e. use it to wrap > your "class" definition that gets instanced, this is somewhat similar to > how I use CommonJS modules)
> On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay ( > http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, > I don't know if is some performance/bad practice issue when I add "extend" > method to Function object.
> On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez > Saldarriaga wrote:
> Hi! :),
> I'm trying to figure it out which one is the best way to reuse code, I'm > reading about Module Pattern and Prototype Inheritance Pattern, seems like > Modules are the hot stuff these days, so I made a little example about how > to implement this thing, but seems like is a little bit complicated, at > least isn't easy as Prototype Inheritance, what do you guys think about > these?.
Well, if all my code is based in classes, isn't the same thing? I mean, if I choose prototype inheritance using Google Closure, I will start creating instances everywhere, one of the things that I try to achieve is this:
* A class with some basic code, like an abstract class. * This "abstract class" in the constructor will have an options object to change some things inside. * Inherit from this "abstract class" to get all normal behavior. * The child class can change the "abstract class" behavior calling the "abstract class" constructor with different options. * The child class can override methods from the "abstract class".
Any thoughts?, maybe you guys can tell me if there's some library or script to achieve this.
Thanks.
-- Juan Felipe Alvarez Saldarriaga http://juan.im Twitter: @nebiros GTalk: nebi...@gmail.com Skype: jfasaldarriaga
On Wednesday, March 28, 2012 at 4:57 PM, Johannes Nel wrote: > why not just use the closure goog.inherits function then. > For memory to become an issue you don't need a large code base, you need many instances or a low powered device.
> On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > Hi!,
> > var MODULE_TWO = (function (old) { > > var my = {}, key;
> > for (key in old) { > > if (old.hasOwnProperty(key)) { > > my[key] = old[key]; > > } > > }
> > var super_moduleMethod = old.moduleMethod; > > my.moduleMethod = function () { > > // override method on the clone, access to super through super_moduleMethod > > };
> > return my; > > }(MODULE));
> > About the memory use, yes, some of the articles below say that, but I think for the reuse code approach isn't matter, at least if you have a really large code base. Maybe the prototype chain approach it's better, but what about multiple inheritance?. I was looking how Google Closure (http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) do this and I came up with this: http://jsfiddle.net/n98dq/
> > On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
> > > The way I've internalised this (and I'm not sure if it's correct, please feel free to jump in)
> > > * The module pattern creates multiple instances of functions instead of using the prototype chain, thus consuming more memory when instances of it are created using the "new" function.
> > > * The module pattern is good for creating "singletons" though.
> > > * The module pattern is good for namespacing code (i.e. use it to wrap your "class" definition that gets instanced, this is somewhat similar to how I use CommonJS modules) > > > Samuel Richardson > > > www.richardson.co.nz (http://www.richardson.co.nz) | 0405 472 748
> > > On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > > > About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay (http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, I don't know if is some performance/bad practice issue when I add "extend" method to Function object.
> > > > On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez Saldarriaga wrote: > > > > > Hi! :),
> > > > > I'm trying to figure it out which one is the best way to reuse code, I'm reading about Module Pattern and Prototype Inheritance Pattern, seems like Modules are the hot stuff these days, so I made a little example about how to implement this thing, but seems like is a little bit complicated, at least isn't easy as Prototype Inheritance, what do you guys think about these?.
I use closure in advanced mode so I am tied to a specific way of constructing classes, but the benefits are enormous. The module pattern is not efficient, this is known, modifying prototypes on the fly is also an iffy practice IMO. I think what you might be after is the mixin strategy. Remember that scope in javascript is "violently" mutable, and mixins trade of this (in)glorious language feature. http://en.wikipedia.org/wiki/Mixin
On Wed, Mar 28, 2012 at 11:19 PM, Juan Felipe Alvarez Saldarriaga <
> Well, if all my code is based in classes, isn't the same thing? I mean, if > I choose prototype inheritance using Google Closure, I will start creating > instances everywhere, one of the things that I try to achieve is this:
> * A class with some basic code, like an abstract class. > * This "abstract class" in the constructor will have an options object to > change some things inside. > * Inherit from this "abstract class" to get all normal behavior. > * The child class can change the "abstract class" behavior calling the > "abstract class" constructor with different options. > * The child class can override methods from the "abstract class".
> Any thoughts?, maybe you guys can tell me if there's some library or > script to achieve this.
> Thanks.
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 4:57 PM, Johannes Nel wrote:
> why not just use the closure goog.inherits function then. > For memory to become an issue you don't need a large code base, you need > many instances or a low powered device.
> On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> var MODULE_TWO = (function (old) { > var my = {}, key; > for (key in old) { > if (old.hasOwnProperty(key)) { > my[key] = old[key]; > } > } > var super_moduleMethod = old.moduleMethod; > my.moduleMethod = function () { > // override method on the clone, access to super through > super_moduleMethod > }; > return my; > }(MODULE));
> About the memory use, yes, some of the articles below say that, but I > think for the reuse code approach isn't matter, at least if you have a > really large code base. Maybe the prototype chain approach it's better, but > what about multiple inheritance?. I was looking how Google Closure ( > http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) > do this and I came up with this: http://jsfiddle.net/n98dq/
> var App = App || {};
> App.Util = (function ($) { > var module = {};
> function inherits(child, parent) { > function I(){}; > I.prototype = parent.prototype; > child.prototype = new I; > child.prototype.constructor = child; > }
> module.inherits = inherits;
> return module; > }(window.jQuery));
> function A() {} > A.prototype.bark = function () { > console.log("A:bark"); > };
> function B() {}
> App.Util.inherits(B, A);
> var b = new B(); > // inspect. > console.log(b); > // bark!. > b.bark();
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
> The way I've internalised this (and I'm not sure if it's correct, please > feel free to jump in)
> * The module pattern creates multiple instances of functions instead of > using the prototype chain, thus consuming more memory when instances of it > are created using the "new" function.
> * The module pattern is good for creating "singletons" though.
> * The module pattern is good for namespacing code (i.e. use it to wrap > your "class" definition that gets instanced, this is somewhat similar to > how I use CommonJS modules)
> On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay ( > http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, > I don't know if is some performance/bad practice issue when I add "extend" > method to Function object.
> On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez > Saldarriaga wrote:
> Hi! :),
> I'm trying to figure it out which one is the best way to reuse code, I'm > reading about Module Pattern and Prototype Inheritance Pattern, seems like > Modules are the hot stuff these days, so I made a little example about how > to implement this thing, but seems like is a little bit complicated, at > least isn't easy as Prototype Inheritance, what do you guys think about > these?.
Yes, I think about mixins too, but don't know how to implement it, yet, about "closures in advanced mode", do you have some example about this approach?.
Thank you.
-- Juan Felipe Alvarez Saldarriaga http://juan.im Twitter: @nebiros GTalk: nebi...@gmail.com Skype: jfasaldarriaga
On Wednesday, March 28, 2012 at 5:31 PM, Johannes Nel wrote: > I use closure in advanced mode so I am tied to a specific way of constructing classes, but the benefits are enormous. The module pattern is not efficient, this is known, modifying prototypes on the fly is also an iffy practice IMO. > I think what you might be after is the mixin strategy. Remember that scope in javascript is "violently" mutable, and mixins trade of this (in)glorious language feature. > http://en.wikipedia.org/wiki/Mixin
> On Wed, Mar 28, 2012 at 11:19 PM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > Hey!,
> > Well, if all my code is based in classes, isn't the same thing? I mean, if I choose prototype inheritance using Google Closure, I will start creating instances everywhere, one of the things that I try to achieve is this:
> > * A class with some basic code, like an abstract class. > > * This "abstract class" in the constructor will have an options object to change some things inside. > > * Inherit from this "abstract class" to get all normal behavior. > > * The child class can change the "abstract class" behavior calling the "abstract class" constructor with different options. > > * The child class can override methods from the "abstract class".
> > Any thoughts?, maybe you guys can tell me if there's some library or script to achieve this.
> > On Wednesday, March 28, 2012 at 4:57 PM, Johannes Nel wrote:
> > > why not just use the closure goog.inherits function then. > > > For memory to become an issue you don't need a large code base, you need many instances or a low powered device.
> > > On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > > > Hi!,
> > > > var super_moduleMethod = old.moduleMethod; > > > > my.moduleMethod = function () { > > > > // override method on the clone, access to super through super_moduleMethod > > > > };
> > > > return my; > > > > }(MODULE));
> > > > About the memory use, yes, some of the articles below say that, but I think for the reuse code approach isn't matter, at least if you have a really large code base. Maybe the prototype chain approach it's better, but what about multiple inheritance?. I was looking how Google Closure (http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) do this and I came up with this: http://jsfiddle.net/n98dq/
> > > > On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
> > > > > The way I've internalised this (and I'm not sure if it's correct, please feel free to jump in)
> > > > > * The module pattern creates multiple instances of functions instead of using the prototype chain, thus consuming more memory when instances of it are created using the "new" function.
> > > > > * The module pattern is good for creating "singletons" though.
> > > > > * The module pattern is good for namespacing code (i.e. use it to wrap your "class" definition that gets instanced, this is somewhat similar to how I use CommonJS modules) > > > > > Samuel Richardson > > > > > www.richardson.co.nz (http://www.richardson.co.nz) | 0405 472 748
> > > > > On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga <nebi...@gmail.com (mailto:nebi...@gmail.com)> wrote: > > > > > > About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay (http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, I don't know if is some performance/bad practice issue when I add "extend" method to Function object.
> > > > > > On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez Saldarriaga wrote: > > > > > > > Hi! :),
> > > > > > > I'm trying to figure it out which one is the best way to reuse code, I'm reading about Module Pattern and Prototype Inheritance Pattern, seems like Modules are the hot stuff these days, so I made a little example about how to implement this thing, but seems like is a little bit complicated, at least isn't easy as Prototype Inheritance, what do you guys think about these?.
> > > > > To unsubscribe from this group, send email to > > > > > jsmentors+unsubscribe@googlegroups.com (mailto:jsmentors+unsubscribe@googlegroups.com)
> > > > -- > > > > To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsment...@jsmentors.com/
> Yes, I think about mixins too, but don't know how to implement it, yet, > about "closures in advanced mode", do you have some example about this > approach?.
> Thank you.
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 5:31 PM, Johannes Nel wrote:
> I use closure in advanced mode so I am tied to a specific way of > constructing classes, but the benefits are enormous. The module pattern is > not efficient, this is known, modifying prototypes on the fly is also an > iffy practice IMO. > I think what you might be after is the mixin strategy. Remember that scope > in javascript is "violently" mutable, and mixins trade of this > (in)glorious language feature. > http://en.wikipedia.org/wiki/Mixin
> On Wed, Mar 28, 2012 at 11:19 PM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> Hey!,
> Well, if all my code is based in classes, isn't the same thing? I mean, if > I choose prototype inheritance using Google Closure, I will start creating > instances everywhere, one of the things that I try to achieve is this:
> * A class with some basic code, like an abstract class. > * This "abstract class" in the constructor will have an options object to > change some things inside. > * Inherit from this "abstract class" to get all normal behavior. > * The child class can change the "abstract class" behavior calling the > "abstract class" constructor with different options. > * The child class can override methods from the "abstract class".
> Any thoughts?, maybe you guys can tell me if there's some library or > script to achieve this.
> Thanks.
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 4:57 PM, Johannes Nel wrote:
> why not just use the closure goog.inherits function then. > For memory to become an issue you don't need a large code base, you need > many instances or a low powered device.
> On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> var MODULE_TWO = (function (old) { > var my = {}, key; > for (key in old) { > if (old.hasOwnProperty(key)) { > my[key] = old[key]; > } > } > var super_moduleMethod = old.moduleMethod; > my.moduleMethod = function () { > // override method on the clone, access to super through > super_moduleMethod > }; > return my; > }(MODULE));
> About the memory use, yes, some of the articles below say that, but I > think for the reuse code approach isn't matter, at least if you have a > really large code base. Maybe the prototype chain approach it's better, but > what about multiple inheritance?. I was looking how Google Closure ( > http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) > do this and I came up with this: http://jsfiddle.net/n98dq/
> var App = App || {};
> App.Util = (function ($) { > var module = {};
> function inherits(child, parent) { > function I(){}; > I.prototype = parent.prototype; > child.prototype = new I; > child.prototype.constructor = child; > }
> module.inherits = inherits;
> return module; > }(window.jQuery));
> function A() {} > A.prototype.bark = function () { > console.log("A:bark"); > };
> function B() {}
> App.Util.inherits(B, A);
> var b = new B(); > // inspect. > console.log(b); > // bark!. > b.bark();
> -- > Juan Felipe Alvarez Saldarriaga > http://juan.im > Twitter: @nebiros > GTalk: nebi...@gmail.com > Skype: jfasaldarriaga
> On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
> The way I've internalised this (and I'm not sure if it's correct, please > feel free to jump in)
> * The module pattern creates multiple instances of functions instead of > using the prototype chain, thus consuming more memory when instances of it > are created using the "new" function.
> * The module pattern is good for creating "singletons" though.
> * The module pattern is good for namespacing code (i.e. use it to wrap > your "class" definition that gets instanced, this is somewhat similar to > how I use CommonJS modules)
> On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
> About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay ( > http://www.3site.eu/doc/), I came up with this: http://jsfiddle.net/d3eqQ/, > I don't know if is some performance/bad practice issue when I add "extend" > method to Function object.
> On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez > Saldarriaga wrote:
> Hi! :),
> I'm trying to figure it out which one is the best way to reuse code, I'm > reading about Module Pattern and Prototype Inheritance Pattern, seems like > Modules are the hot stuff these days, so I made a little example about how > to implement this thing, but seems like is a little bit complicated, at > least isn't easy as Prototype Inheritance, what do you guys think about > these?.
> On Wednesday, March 28, 2012 6:31:28 PM UTC-4, Johannes Nel wrote:
> scope in javascript is "violently" mutable
> Ahahahaha. I love it. I've never heard it described that way.
That's probably a good thing, because as far as I know scope in JS is completely immutable (barring eval acrobatics). "Scope" refers to the lexical environment in which variables and functions are resolved; it is directly related to the program structure and exists independently of the conditions at runtime. What Johannes probably meant was the "this" value, which is the exact opposite: it cannot always be inferred from the program structure and depends instead on how a function is called at runtime. This is also sometimes referred to as "context", but never as "scope". Or at least, it shouldn't be, if you want to keep your terminology straight.
what you say this is true in cs terms and yes, i was referring to the resolution of the this. Although (and by no means would I recommend doing this) __proto__ was another way to cheat the system.
On Thu, Mar 29, 2012 at 12:12 AM, Stefan Weiss <we...@foo.at> wrote: > On 2012-03-29 00:38, Jay Young wrote: > > On Wednesday, March 28, 2012 6:31:28 PM UTC-4, Johannes Nel wrote:
> > scope in javascript is "violently" mutable
> > Ahahahaha. I love it. I've never heard it described that way.
> That's probably a good thing, because as far as I know scope in JS is > completely immutable (barring eval acrobatics). "Scope" refers to the > lexical environment in which variables and functions are resolved; it is > directly related to the program structure and exists independently of > the conditions at runtime. What Johannes probably meant was the "this" > value, which is the exact opposite: it cannot always be inferred from > the program structure and depends instead on how a function is called at > runtime. This is also sometimes referred to as "context", but never as > "scope". Or at least, it shouldn't be, if you want to keep your > terminology straight.
> I'm trying to figure it out which one is the best way to reuse code, > I'm reading about Module Pattern and Prototype Inheritance Pattern, > seems like Modules are the hot stuff these days,
Both? All three? Depends on the problem?-)
module pattern: local variable scope modules: namespaces with import/export/separate files prototypes: inheritance by delegation/sharing
So, your inheritance chains go into modules (possibly more than one module per chain), which probably use the module pattern and some module loader (unless there is a predefined module system, as in nodejs). A simplified form of the module pattern might be used to provide local scope for defining prototype chains in (eg, for private variables).
Module pattern might be used less when block-scoping arrives, modules and loaders will then be built in, prototype chains may have class sugar:
> I use google closure with advanced mode compilation :)
> On Wed, Mar 28, 2012 at 11:37 PM, Juan Felipe Alvarez Saldarriaga < > nebi...@gmail.com> wrote:
>> Nice!,
>> Yes, I think about mixins too, but don't know how to implement it, yet, >> about "closures in advanced mode", do you have some example about this >> approach?.
>> Thank you.
>> -- >> Juan Felipe Alvarez Saldarriaga >> http://juan.im >> Twitter: @nebiros >> GTalk: nebi...@gmail.com >> Skype: jfasaldarriaga
>> On Wednesday, March 28, 2012 at 5:31 PM, Johannes Nel wrote:
>> I use closure in advanced mode so I am tied to a specific way of >> constructing classes, but the benefits are enormous. The module pattern is >> not efficient, this is known, modifying prototypes on the fly is also an >> iffy practice IMO. >> I think what you might be after is the mixin strategy. Remember that >> scope in javascript is "violently" mutable, and mixins trade of this >> (in)glorious language feature. >> http://en.wikipedia.org/wiki/Mixin
>> On Wed, Mar 28, 2012 at 11:19 PM, Juan Felipe Alvarez Saldarriaga < >> nebi...@gmail.com> wrote:
>> Hey!,
>> Well, if all my code is based in classes, isn't the same thing? I mean, >> if I choose prototype inheritance using Google Closure, I will start >> creating instances everywhere, one of the things that I try to achieve is >> this:
>> * A class with some basic code, like an abstract class. >> * This "abstract class" in the constructor will have an options object to >> change some things inside. >> * Inherit from this "abstract class" to get all normal behavior. >> * The child class can change the "abstract class" behavior calling the >> "abstract class" constructor with different options. >> * The child class can override methods from the "abstract class".
>> Any thoughts?, maybe you guys can tell me if there's some library or >> script to achieve this.
>> Thanks.
>> -- >> Juan Felipe Alvarez Saldarriaga >> http://juan.im >> Twitter: @nebiros >> GTalk: nebi...@gmail.com >> Skype: jfasaldarriaga
>> On Wednesday, March 28, 2012 at 4:57 PM, Johannes Nel wrote:
>> why not just use the closure goog.inherits function then. >> For memory to become an issue you don't need a large code base, you need >> many instances or a low powered device.
>> On Wed, Mar 28, 2012 at 10:52 PM, Juan Felipe Alvarez Saldarriaga < >> nebi...@gmail.com> wrote:
>> var MODULE_TWO = (function (old) { >> var my = {}, key; >> for (key in old) { >> if (old.hasOwnProperty(key)) { >> my[key] = old[key]; >> } >> } >> var super_moduleMethod = old.moduleMethod; >> my.moduleMethod = function () { >> // override method on the clone, access to super through >> super_moduleMethod >> }; >> return my; >> }(MODULE));
>> About the memory use, yes, some of the articles below say that, but I >> think for the reuse code approach isn't matter, at least if you have a >> really large code base. Maybe the prototype chain approach it's better, but >> what about multiple inheritance?. I was looking how Google Closure ( >> http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.s...) >> do this and I came up with this: http://jsfiddle.net/n98dq/
>> var App = App || {};
>> App.Util = (function ($) { >> var module = {};
>> function inherits(child, parent) { >> function I(){}; >> I.prototype = parent.prototype; >> child.prototype = new I; >> child.prototype.constructor = child; >> }
>> module.inherits = inherits;
>> return module; >> }(window.jQuery));
>> function A() {} >> A.prototype.bark = function () { >> console.log("A:bark"); >> };
>> function B() {}
>> App.Util.inherits(B, A);
>> var b = new B(); >> // inspect. >> console.log(b); >> // bark!. >> b.bark();
>> -- >> Juan Felipe Alvarez Saldarriaga >> http://juan.im >> Twitter: @nebiros >> GTalk: nebi...@gmail.com >> Skype: jfasaldarriaga
>> On Wednesday, March 28, 2012 at 4:37 PM, Samuel Richardson wrote:
>> The way I've internalised this (and I'm not sure if it's correct, please >> feel free to jump in)
>> * The module pattern creates multiple instances of functions instead of >> using the prototype chain, thus consuming more memory when instances of it >> are created using the "new" function.
>> * The module pattern is good for creating "singletons" though.
>> * The module pattern is good for namespacing code (i.e. use it to wrap >> your "class" definition that gets instanced, this is somewhat similar to >> how I use CommonJS modules)
>> On Thu, Mar 29, 2012 at 4:10 AM, Juan Felipe Alvarez Saldarriaga < >> nebi...@gmail.com> wrote:
>> About Prototype Inheritance Pattern and reading Andrea Giammarchi's essay >> (http://www.3site.eu/doc/), I came up with this: >> http://jsfiddle.net/d3eqQ/, I don't know if is some performance/bad >> practice issue when I add "extend" method to Function object.
>> On Wednesday, March 28, 2012 11:33:51 AM UTC-5, Juan Felipe Alvarez >> Saldarriaga wrote:
>> Hi! :),
>> I'm trying to figure it out which one is the best way to reuse code, I'm >> reading about Module Pattern and Prototype Inheritance Pattern, seems like >> Modules are the hot stuff these days, so I made a little example about how >> to implement this thing, but seems like is a little bit complicated, at >> least isn't easy as Prototype Inheritance, what do you guys think about >> these?.
On Thursday, March 29, 2012 at 3:08 AM, Claus Reinke wrote: > > I'm trying to figure it out which one is the best way to reuse code, > > I'm reading about Module Pattern and Prototype Inheritance Pattern, > > seems like Modules are the hot stuff these days,
> Both? All three? Depends on the problem?-)
> module pattern: > local variable scope > modules: > namespaces with import/export/separate files > prototypes: > inheritance by delegation/sharing
> So, your inheritance chains go into modules (possibly more than > one module per chain), which probably use the module pattern > and some module loader (unless there is a predefined module > system, as in nodejs). A simplified form of the module pattern > might be used to provide local scope for defining prototype > chains in (eg, for private variables).
> Module pattern might be used less when block-scoping arrives, > modules and loaders will then be built in, prototype chains may > have class sugar:
- Split things into smaller functions/methods/objects/modules, making it easier to overwrite and reuse. - Avoid inheritance as much as possible, not because of performance or anything similar, but because inheritance is overrated and can make things more complex than needed. - Avoid private members as much as possible since it makes it "impossible" to overwrite the behavior. - Avoid "classes" (constructor functions) as much as possible since in many times what you really need is a function, not a class. Also sometimes you are sure you will only need a single instance, some people might say that singletons/static classes are an anti-pattern but it varies depending on each case. - Avoid plugins, your code should be "modular", treat everything as an individual piece (you should be able to reuse same code in a diff project without any configuration), don't augment objects you don't own. - (ab)use `Function.call` and `Function.apply`.
"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." - John Carmack
More details about the things I said above in case anyone is interested:
>> I'm trying to figure it out which one is the best way to reuse code, >> I'm reading about Module Pattern and Prototype Inheritance Pattern, >> seems like Modules are the hot stuff these days,
>Both? All three? Depends on the problem?-)
>module pattern: > local variable scope >modules: > namespaces with import/export/separate files >prototypes: > inheritance by delegation/sharing
>So, your inheritance chains go into modules (possibly more than >one module per chain), which probably use the module pattern >and some module loader (unless there is a predefined module >system, as in nodejs). A simplified form of the module pattern >might be used to provide local scope for defining prototype >chains in (eg, for private variables).
>Module pattern might be used less when block-scoping arrives, >modules and loaders will then be built in, prototype chains may >have class sugar:
Miller Medeiros wrote:
> - Split things into smaller functions/methods/objects/modules, making it
> easier to overwrite and reuse.
> - Avoid inheritance as much as possible, not because of performance or
> anything similar, but because inheritance is overrated and can make things
> more complex than needed.
OK so far.
> - Avoid private members as much as possible since it makes it
> "impossible" to overwrite the behavior.
But that's really the point of private methods. If a function is
meant to be used as an implementation detail, it should be kept
private. No one should ever be able to override anything but the
public behavior. I did read your blog post on the subject, and I'm
not convinced. My main problem is that you get stuck with the public
API you present. The more of it you expose (even if you use leading
underscores as a warning) the less flexibility you have in changing
the implementation later.
