Hi guys! i am fairly new to this web2.0 thingie and still developing my
Javascript skills.
i have seen the yui and prototype-scriptaculous library and i found both to
be compellingly rich.
both Prototype and Scriptaculous declares their respective namespace like
this:
var ObjectName = {
propertyOne: propertyValue,
methodOne: function (argv1, argv2) {
//do something here
}
}
while YUI does something like this:
var ObjectName = function () {
return {
propertyOne: propertyValue,
methodOne: function (argv1,argv2) {
//do something here...
}
}
}();
they both seem to work fine, but are there any difference? performace wise?
thanks in advance!
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
They will most likely end up being very close in performance but I find the prototype/scriptaculous to be more programmer friendly. Brandon On 7/20/06, Brian Feliciano <redbaks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hi guys! i am fairly new to this web2.0 thingie and still developing my > Javascript skills. > i have seen the yui and prototype-scriptaculous library and i found both > to be compellingly rich. > > both Prototype and Scriptaculous declares their respective namespace like > this: > > var ObjectName = { > propertyOne: propertyValue, > methodOne: function (argv1, argv2) { > //do something here > } > } > > while YUI does something like this: > > var ObjectName = function () { > return { > propertyOne: propertyValue, > methodOne: function (argv1,argv2) { > //do something here... > } > } > }(); > > they both seem to work fine, but are there any difference? performace > wise? > > thanks in advance! > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
When you say "most likelty end up being very close in performance" are you favoring the yui way or the proto way? i am about to create a js app based on prototype and i am really concerned about speed and performance. (i am almost feel awkward posting this to a rails community, since i''m not user. forgive me :D ) btw, thanks brandon. On 7/20/06, Brandon Aaron <brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > They will most likely end up being very close in performance but I find > the prototype/scriptaculous to be more programmer friendly. > > Brandon >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
I''d reckon less than half the list are rails developers, so no worries. If I had to guess, without having concrete numbers, I''d say YUI is likely faster in general. Procedural programming is usually faster than object-oriented programming. That said, Prototype is a lot more flexible and gives you a lot of handy methods for writing concise code. So, I go with prototype, but your situation might be different. Greg ________________________________ From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Brian Feliciano Sent: Thursday, July 20, 2006 9:40 AM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails-spinoffs] Javascript Namespacing Question When you say "most likelty end up being very close in performance" are you favoring the yui way or the proto way? i am about to create a js app based on prototype and i am really concerned about speed and performance. (i am almost feel awkward posting this to a rails community, since i''m not user. forgive me :D ) btw, thanks brandon. On 7/20/06, Brandon Aaron <brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: They will most likely end up being very close in performance but I find the prototype/scriptaculous to be more programmer friendly. Brandon _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
The only stumbling block I have yet to fall down on in proto/scriptaculous as far as performance goes is when I have a ton of Draggables/Droppables instances on a page at a time. I have engineered my own solution to that problem though and others here have done similar, so if you get there just ask us about it and we shall help. If you get to a point where you have to optimize loops to shave milliseconds, neither library is going to offer you any advantages/disadvantages, you''ve walked in no man''s land and it''s back to straight javascript fundamentals. Where proto shines is the clean class based OO style and the lexical scope preservation abstractions. You will not have problems with it''s performance, and like I said, if you are, then YUI will be no better for your app. PS: Don''t worry about not using RoR... I''m a .NET guy and have never written a lick of Ruby. On 7/20/06, Brian Feliciano <redbaks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > When you say "most likelty end up being very close in performance" are you > favoring the yui way or the proto way? > i am about to create a js app based on prototype and i am really concerned > about speed and performance. > > (i am almost feel awkward posting this to a rails community, since i''m not > user. forgive me :D ) > > btw, thanks brandon. > > > On 7/20/06, Brandon Aaron <brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > They will most likely end up being very close in performance but I find > > the prototype/scriptaculous to be more programmer friendly. > > > > Brandon > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Anyway, my base is still going to be prototype. But is there any
difference/problem if i use the yui namespacing and proceed with object
notation?
something like:
var ObjectName = function (){
return {
propertyOne: propertyValue,
methodOne: function () {},
sub: {},
}
}();
ObjectName.sub.ClassOne = Class.create();
ObjectName.sub.ClassOne.prototype = {
//do some stuff here
};
ObjectName.sub.ObjectTwo = {
// do more stuff here..
};
thanks for helping out a newbie.
On 7/21/06, Hill, Greg <grhill-W2hqgAdRMsX2eFz/2MeuCQ@public.gmane.org>
wrote:>
> I''d reckon less than half the list are rails developers, so no
worries.
> If I had to guess, without having concrete numbers, I''d say YUI is
likely
> faster in general. Procedural programming is usually faster than
> object-oriented programming. That said, Prototype is a lot more flexible
> and gives you a lot of handy methods for writing concise code. So, I go
> with prototype, but your situation might be different.
>
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Nope, that should work out just fine, but I would just call that "namespacing" (YUI didn''t invent that concept)... :-) On 7/20/06, Brian Feliciano <redbaks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Anyway, my base is still going to be prototype. But is there any > difference/problem if i use the yui namespacing and proceed with object > notation? > something like: > > > var ObjectName = function (){ > return { > propertyOne: propertyValue, > methodOne: function () {}, > sub: {}, > } > }(); > > ObjectName.sub.ClassOne = Class.create(); > ObjectName.sub.ClassOne.prototype = { > //do some stuff here > }; > > ObjectName.sub.ObjectTwo = { > // do more stuff here.. > }; > > thanks for helping out a newbie. > > > > On 7/21/06, Hill, Greg <grhill-W2hqgAdRMsX2eFz/2MeuCQ@public.gmane.org > wrote: > > > > I''d reckon less than half the list are rails developers, so no > > worries. If I had to guess, without having concrete numbers, I''d say YUI is > > likely faster in general. Procedural programming is usually faster than > > object-oriented programming. That said, Prototype is a lot more flexible > > and gives you a lot of handy methods for writing concise code. So, I go > > with prototype, but your situation might be different. > > > > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
I personally prefer prototype because of what I believe is a programmer friendly object oriented-ish design. The only time I''ve really run into performance issues was in dealing with large numbers of Draggables and Droppables.. but that''s already been covered at length in previous list topics. (By the way, thanks Ryan for the lazy loading article :) Welcome to the list! Rails is not a requirement. Heck, I only recently started learning Ruby after I had started learning a little .NET. (I just know I''ll get hassled about this at my next Rails users group meeting... ) As for your namespacing YUI style vs. Prototype, I don''t forsee a problem as long as you keep straight which parts follow your YUI standard and which are prototype. It''s up to you. Cheers, Joe -----Original Message----- From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]On Behalf Of Brian Feliciano Sent: Thursday, July 20, 2006 11:40 AM To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: Re: [Rails-spinoffs] JavaScript Namespacing Question When you say "most likelty end up being very close in performance" are you favoring the yui way or the proto way? i am about to create a js app based on prototype and i am really concerned about speed and performance. (i am almost feel awkward posting this to a rails community, since i''m not user. forgive me :D ) btw, thanks brandon. On 7/20/06, Brandon Aaron <brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: They will most likely end up being very close in performance but I find the prototype/scriptaculous to be more programmer friendly. Brandon
wow! this list is hot! :D
thanks for the instant replies! i''m starting to love this list. :D
my last question ( of this thread :D )
is there a difference between:
var ObjectName = Class.create();
ObjectName.prototype = {
initialize: function () {},
doThis: function () {}
}
var obj = new ObjectName();
obj.doThis();
and
var ObjectName = {
initialize: function () {},
doThis: function () {}
}
ObjectName.doThis();
i know their difference coding-wise, but im a bit concerned about speed and
performance and efficiency. (as you may have already noticed, im a bit
paranoid about performance/speed)
On 7/21/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
> Nope, that should work out just fine, but I would just call that
> "namespacing" (YUI didn''t invent that concept)... :-)
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
I believe the only difference between the two is that in the first
you''re creating a prototyped class, where in the second you''re
creating a static namespace containing functions.
The only extra overhead you''ll see is from the call to Class.create().
Cheers,
Joe
-----Original Message-----
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]On
Behalf Of Brian Feliciano
Sent: Thursday, July 20, 2006 12:28 PM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails-spinoffs] Javascript Namespacing Question
wow! this list is hot! :D
thanks for the instant replies! i''m starting to love this list. :D
my last question ( of this thread :D )
is there a difference between:
var ObjectName = Class.create();
ObjectName.prototype = {
initialize: function () {},
doThis: function () {}
}
var obj = new ObjectName();
obj.doThis();
and
var ObjectName = {
initialize: function () {},
doThis: function () {}
}
ObjectName.doThis();
i know their difference coding-wise, but im a bit concerned about speed and
performance and efficiency. (as you may have already noticed, im a bit paranoid
about performance/speed)
On 7/21/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
Nope, that should work out just fine, but I would just call that
"namespacing" (YUI didn''t invent that concept)... :-)
Your second example simply implies doSomething is a static method of the ObjectName class (i.e. instantiation is not necessary) and is a perfect testament to how proto accurately and easily allows for traditional OO programming styles... in that case just be aware that the function is executing in a static context and "this" will refer to the function itself (unless you .bind() the call to another object). On 7/20/06, Bauser, Joseph (Joe) <Joseph.Bauser-9sMr025MA47QT0dZR+AlfA@public.gmane.org> wrote:> > I believe the only difference between the two is that in the first you''re > creating a prototyped class, where in the second you''re creating a static > namespace containing functions. > > The only extra overhead you''ll see is from the call to Class.create(). > > Cheers, > Joe > > -----Original Message----- > From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto: > rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]On Behalf Of Brian Feliciano > Sent: Thursday, July 20, 2006 12:28 PM > To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails-spinoffs] Javascript Namespacing Question > > > wow! this list is hot! :D > thanks for the instant replies! i''m starting to love this list. :D > > my last question ( of this thread :D ) > is there a difference between: > > var ObjectName = Class.create(); > ObjectName.prototype = { > initialize: function () {}, > doThis: function () {} > } > var obj = new ObjectName(); > obj.doThis(); > > and > > var ObjectName = { > initialize: function () {}, > doThis: function () {} > } > ObjectName.doThis(); > > i know their difference coding-wise, but im a bit concerned about speed > and performance and efficiency. (as you may have already noticed, im a bit > paranoid about performance/speed) > > > > > On 7/21/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > Nope, that should work out just fine, but I would just call that > "namespacing" (YUI didn''t invent that concept)... :-) > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Brian Feliciano wrote:> while YUI does something like this: > > var ObjectName = function () { > return { > propertyOne: propertyValue, > methodOne: function (argv1,argv2) { > //do something here... > } > } > }(); > > they both seem to work fine, but are there any difference? performace wise?I have not worked with YUI (prototype has been more than adequate for me so I have not investigated others) but the main difference I see with the above code is that it allows for private variables/methods to be easily defined. Consider the following modification on the above code: var ObjectName = function () { var myPrivateVariable = ''secret''; function myPrivateMethod(arg1, arg2) { // ... do something private ... } return { propertyOne: propertyValue, methodOne: function (argv1,argv2) { alert(myPrivateVariable); myPrivateMethod(argv1, argv2); } } }(); In this example we have a private variable and a private method that cannot be accessed from outside of "ObjectName" but are perfectly accessible inside "ObjectName" because of the closure. May cause memory leaks if you reference host objects though... Would have to be careful about that. Prototype takes the "advisory" approach to making methods private. For example the collection objects (Hash, Array, RangeObject) all define a "_each" method that is used by the Enumerable mixin for iteration. This "_each" method is private (or maybe it would be considered protected?) but it does not enforce this restriction. You know it is internal because of the "_". You can obey that restriction (by using the "each" method which is meant for public use) or you can ignore the restriction and use "_each" directly (perhaps you want a performance benefit by avoiding the try...catch expression since you may not be using the $break and $continue exceptions anyway). Some people prefer enforcing member protection, others prefer the advisory method. My guess is that Prototype takes the advisory approach because of it''s ancestry in dynamic languages like Ruby and Perl which also tend to use the advisory method. I think the idea is to encourage people to not shoot themselves in the foot but allow them to do so if they really want since ideally the user of the library knows more about their own domain than the developer of the library. Eric
JavaScript is a prototype-based OO language. Search on Google for the "Self" programming language for more info on this concept since it is the pioneer in this type of OO. Brian Feliciano wrote:> is there a difference between: > > var ObjectName = Class.create(); > ObjectName.prototype = { > initialize: function () {}, > doThis: function () {} > } > var obj = new ObjectName(); > obj.doThis();In this case you are creating a prototype object (located at ObjectName.prototype) and defining a constructor function which will spawn a new object from that prototype object, executing that constructor function to create your new object then executing a method on that new object. You can think of this as somewhat like doing the following (it is a bit different but I''m trying to keep just the core concepts here): ObjectName.prototype = { initialize: function () {}, doThis: function () {} } var obj = new Object(); obj.prototype = ObjectName.prototype; obj.initialize(); obj.doThis(); What Prototype is trying to do here is trying to simulate class-based OO on top of the built-in prototype-based OO. The idea is to treat the object "ObjectName" as the class (and methods defined on this object would be considered class methods). Instance methods are defined on "ObjectName.prototype". "initialize" is your constructor for creating new instances of your class. The goals is to make JavaScript more comfortable to developers who are used to class-based OO that most OO languages implement (Ruby, C#, Java, etc.)> var ObjectName = { > initialize: function () {}, > doThis: function () {} > } > ObjectName.doThis();This on the other hand is just using normal prototype-based OO. Here you are creating an object literal (the stuff inside the {}) with your methods defined and assigning that object literal to the identifier "ObjectName". You are this using that object as a normal instance without worrying about defining abstract concepts like classes. It is important to note that your "initialize" method is not automatically executed for you. That is something that prototype does for you when you execute "Class.create()" (it defines a constructor function which will execute "initialize" on the new instance being created). No constructor is run when using an object literal. Only if you define a constructor function and create new instances from the constructor function''s prototype object is a constructor executed. Eric
Brian Feliciano wrote:> i know their difference coding-wise, but im a bit concerned about speed > and performance and efficiency. (as you may have already noticed, im a > bit paranoid about performance/speed)One more thing. The class-based OO emulated by prototype will be slightly slower because it is doing more work than using a single classless object. But make you decision on what is the most maintainable not on the speed. There will not be a noticeable difference between the two. The class emulation provided by prototype is just a thin wrapper around the way JavaScript normally spawns new objects from prototype objects so it is in line with the way JavaScript is supposed to work. If you need many instances of an object use the support JavaScript provides to generate many similar instances from a prototype object or use the class emulation that prototype provides if that makes more sense to you. Only make performance decisions after you have profiled your code and determined the hot spots. Otherwise you will be just wasting time saving no more than a few instructions. Eric
The beauty though, Eric, is that you can use prototype to achieve this as
well. People have a habit of putting boxes around things and imposing
imaginary constraints. Look outside the box you''ve (not you
specifically,
Eric, that''s the general "you") put the powerful prototype.js
into and
you''ll see it provides the means for a complete classical OO style,
including private members, interfaces, enums, etc..., which greatly (greatly
I say) improves code readability, re-use, refactorability, concern and
behavior separation, etc...
PRIVATE MEMBERS IN PROTOTYPE:
The trick is encapsulating the class definition as a whole inside the
contructor method (using bind() to preserve the lexical scope of the
containing class), which adds little to no overhead to instantiation since
the methods would have to be created in memory anyway...
myObject = Class.create();
myObject.prototype = {
initialize: function() {
var privateVariable1 = "I''m private";
var privateFunction1 = function() {
alert(privateVariable1);
};
//now define the public members
Object.extend(this, {
publicVariable1: "I''m public",
publicMethod1: function() {
//make a call to the private function
privateFunction1();
}.bind(this)
});
}
};
>> snip:
>> What Prototype is trying to do here is trying to simulate class-based
OO
>> on top of the built-in prototype-based OO
Exactly, Eric, and it does so with tremendous success. There are many
advantages to classical OO, and proto gives you that, plus you always have
the underlying prototype system of js if you want it (2 OO paradigms at your
disposal, wonderful!).
On 7/20/06, Eric Anderson <eric-ANzg6odk14w@public.gmane.org>
wrote:>
> Brian Feliciano wrote:
> > while YUI does something like this:
> >
> > var ObjectName = function () {
> > return {
> > propertyOne: propertyValue,
> > methodOne: function (argv1,argv2) {
> > //do something here...
> > }
> > }
> > }();
> >
> > they both seem to work fine, but are there any difference? performace
> wise?
>
> I have not worked with YUI (prototype has been more than adequate for me
> so I have not investigated others) but the main difference I see with
> the above code is that it allows for private variables/methods to be
> easily defined. Consider the following modification on the above code:
>
> var ObjectName = function () {
> var myPrivateVariable = ''secret'';
> function myPrivateMethod(arg1, arg2) {
> // ... do something private ...
> }
>
> return {
> propertyOne: propertyValue,
> methodOne: function (argv1,argv2) {
> alert(myPrivateVariable);
> myPrivateMethod(argv1, argv2);
> }
> }
> }();
>
> In this example we have a private variable and a private method that
> cannot be accessed from outside of "ObjectName" but are perfectly
> accessible inside "ObjectName" because of the closure. May cause
memory
> leaks if you reference host objects though... Would have to be careful
> about that.
>
> Prototype takes the "advisory" approach to making methods
private. For
> example the collection objects (Hash, Array, RangeObject) all define a
> "_each" method that is used by the Enumerable mixin for
iteration. This
> "_each" method is private (or maybe it would be considered
protected?)
> but it does not enforce this restriction. You know it is internal
> because of the "_". You can obey that restriction (by using the
"each"
> method which is meant for public use) or you can ignore the restriction
> and use "_each" directly (perhaps you want a performance benefit
by
> avoiding the try...catch expression since you may not be using the
> $break and $continue exceptions anyway).
>
> Some people prefer enforcing member protection, others prefer the
> advisory method. My guess is that Prototype takes the advisory approach
> because of it''s ancestry in dynamic languages like Ruby and Perl
which
> also tend to use the advisory method. I think the idea is to encourage
> people to not shoot themselves in the foot but allow them to do so if
> they really want since ideally the user of the library knows more about
> their own domain than the developer of the library.
>
> Eric
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Some who read my code for this may point out that the Object.extend() was
unnecessary, that I could have just done "this.publicVariable1 = ..."
and "
this.publicMethod1 = function(...) {...};", but I like to keep these things
together using my initial syntax, which lends itself well to other tasks
like overridding, overloading, interface implementations, (as well as
refactoring) etc... the point was that proto makes it _easy_ to apply sound
classical OO.
On 7/20/06, Ryan Gahl <ryan.gahl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:>
> The beauty though, Eric, is that you can use prototype to achieve this as
> well. People have a habit of putting boxes around things and imposing
> imaginary constraints. Look outside the box you''ve (not you
specifically,
> Eric, that''s the general "you") put the powerful
prototype.js into and
> you''ll see it provides the means for a complete classical OO
style,
> including private members, interfaces, enums, etc..., which greatly
(greatly
> I say) improves code readability, re-use, refactorability, concern and
> behavior separation, etc...
>
> PRIVATE MEMBERS IN PROTOTYPE:
> The trick is encapsulating the class definition as a whole inside the
> contructor method (using bind() to preserve the lexical scope of the
> containing class), which adds little to no overhead to instantiation since
> the methods would have to be created in memory anyway...
>
> myObject = Class.create();
> myObject.prototype = {
> initialize: function() {
> var privateVariable1 = "I''m private";
> var privateFunction1 = function() {
> alert(privateVariable1);
> };
>
> //now define the public members
> Object.extend(this, {
> publicVariable1: "I''m public",
> publicMethod1: function() {
> //make a call to the private function
> privateFunction1();
> }.bind(this)
> });
> }
> };
>
>
>
> >> snip:
>
> >> What Prototype is trying to do here is trying to simulate
class-based
> OO
> >> on top of the built-in prototype-based OO
>
> Exactly, Eric, and it does so with tremendous success. There are many
> advantages to classical OO, and proto gives you that, plus you always have
> the underlying prototype system of js if you want it (2 OO paradigms at
your
> disposal, wonderful!).
>
>
> On 7/20/06, Eric Anderson <eric-ANzg6odk14w@public.gmane.org> wrote:
> >
> > Brian Feliciano wrote:
> > > while YUI does something like this:
> > >
> > > var ObjectName = function () {
> > > return {
> > > propertyOne: propertyValue,
> > > methodOne: function (argv1,argv2) {
> > > //do something here...
> > > }
> > > }
> > > }();
> > >
> > > they both seem to work fine, but are there any difference?
performace
> > wise?
> >
> > I have not worked with YUI (prototype has been more than adequate for
me
> >
> > so I have not investigated others) but the main difference I see with
> > the above code is that it allows for private variables/methods to be
> > easily defined. Consider the following modification on the above code:
> >
> > var ObjectName = function () {
> > var myPrivateVariable = ''secret'';
> > function myPrivateMethod(arg1, arg2) {
> > // ... do something private ...
> > }
> >
> > return {
> > propertyOne: propertyValue,
> > methodOne: function (argv1,argv2) {
> > alert(myPrivateVariable);
> > myPrivateMethod(argv1, argv2);
> > }
> > }
> > }();
> >
> > In this example we have a private variable and a private method that
> > cannot be accessed from outside of "ObjectName" but are
perfectly
> > accessible inside "ObjectName" because of the closure. May
cause memory
> > leaks if you reference host objects though... Would have to be careful
> > about that.
> >
> > Prototype takes the "advisory" approach to making methods
private. For
> > example the collection objects (Hash, Array, RangeObject) all define a
> > "_each" method that is used by the Enumerable mixin for
iteration. This
> > "_each" method is private (or maybe it would be considered
protected?)
> > but it does not enforce this restriction. You know it is internal
> > because of the "_". You can obey that restriction (by using
the "each"
> > method which is meant for public use) or you can ignore the
restriction
> > and use "_each" directly (perhaps you want a performance
benefit by
> > avoiding the try...catch expression since you may not be using the
> > $break and $continue exceptions anyway).
> >
> > Some people prefer enforcing member protection, others prefer the
> > advisory method. My guess is that Prototype takes the advisory
approach
> > because of it''s ancestry in dynamic languages like Ruby and
Perl which
> > also tend to use the advisory method. I think the idea is to encourage
> > people to not shoot themselves in the foot but allow them to do so if
> > they really want since ideally the user of the library knows more
about
> > their own domain than the developer of the library.
> >
> > Eric
> >
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> >
>
>
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Ryan Gahl wrote:> The beauty though, Eric, is that you can use prototype to achieve this > as well.Of course you can do private properties when using prototype. The support for doing so is provided by closures in the JavaScript language so you can do that with any JavaScript framework. All I was saying is that the YUI example given (which I am not familiar with) seems to encourage this behavior. But you can implement it with any framework. I don''t see prototype as helping you with this much. It is just part of the language (behavior of closures).> prototype.js into and you''ll see it provides the means for a complete > classical OO style, including private members, interfaces, enums, > etc..., which greatly (greatly I say) improves code readability, re-use, > refactorability, concern and behavior separation, etc...I will have to disagree with you on this point. Although doing private properties can be done with Javascript (using closures) I don''t see prototype as helping you with this any. The code example you gave below seems quite unreadable to me (no offense, just my opinion of the readability). Look at the loops that we are jumping through:> The trick is encapsulating the class definition as a whole inside the > contructor method (using bind() to preserve the lexical scope of the > containing class),Both of these actions seem very unfriendly to me. Having to define my entire object inside the constructor? Appending a bind(this) to every method I create? Private properties have questionable value if it is easy to use. If I have to go through a lot of work the value does not make up for the increased code complexity in my opinion.> which adds little to no overhead to instantiation > since the methods would have to be created in memory anyway...It will add overhead because each instance of "myObject" will have it''s own property instead of all instances accessing the property through the prototype chain. Although the difference is so small nobody will know. :) This also bucks the system because people expect the prototype object to define common methods instead of each object having it''s own reference to the method. Normally I can do: myObject.prototype.publicMethod = function() { // ... some implementation ... } and expect that to redefine "publicMethod" for all instances of myObject (already instantiated or not). But in this case I am defining the method in the wrong location because the method is defined inside the constructor removing the ability to redefine prototype properties.> Exactly, Eric, and it does so with tremendous success. There are many > advantages to classical OO, and proto gives you that, plus you always > have the underlying prototype system of js if you want it (2 OO > paradigms at your disposal, wonderful!).I agree that having both systems at your disposal is good. From what I have heard the "standards people" (whoever they are) are looking to add real classes to EMCAScript soon (and ActionScript which I believe is EMCAScript compliant has already done that) so I think many others would agree both systems are good. But I disagree that prototype does it will tremendous success. I consider the class-based OO emulation adequate but not elegant. It was approaching elegant when "extend" extended Object.prototype but of course that broke language conventions so it had to be moved to "Object" which was less elegant. From what I have read Sam Stephenson is not really happy with the current class-based OO emulation. See: http://sam.conio.net/ Specifically "Prototype’s class system is definitely experiencing growing pains" and "You can expect Base to make its way into Prototype 2.0 in a form that’s backwards-compatible with Class.create and Object.extend." indicates to me that the current system (Class.create and Object.extend) is not considered ideal. I think having some sort of class-based OO emulation is good but I would hardly call the current implementation a tremendous success. It is adequate and the rest of prototype/scriptaculous rocks so much that we still use prototype with enthusiasm. But I think many people will be happy to get a more elegant system in place. Just my opinion Eric
>> The trick is encapsulating the class definition as a whole inside the >> contructor method (using bind() to preserve the lexical scope of the >> containing class),> Both of these actions seem very unfriendly to me. Having to define my > entire object inside the constructor? Appending a bind(this) to every > method I create? Private properties have questionable value if it is > easy to use. If I have to go through a lot of work the value does not > make up for the increased code complexity in my opinion.First of all, if you have adopted proto as your base, and classical OO is the programming model you are consistently enforcing across the development cycle/project/team, then this is no extra work and in fact saves much effort via prototype. Now, consider the following class and subclass (or Objects if that''s what you prefer). To determine if proto makes it MUCH easier to achieve these various classical constructs (or not, as you claim), I''ll create them using prototype and you create it without (making sure to obey the same private/public/instance/static/superclass/subclass object model as my classes). There are really only 3 prototype calls I''ll make, just to isolate the comparison (Class.create(), Object.extend(), and bind()). I''m interested to see which style looks cleaner and lends itself better to re-use and refactoring (and to be objective I''ll qualify that with which style looks better to _other_ people, as I''m sure I''m biased towards my style and you towards yours). I''m not trying to turn this into any kind of battle, I just really think people are a) taking for granted the power of just those 3 simple functions, and b) not looking enough outside the box to really see what proto can do (or how much easier it can make certain things if classical OO is important to you, which for a good majority of people on this list I''m guessing it is). Consider all that''s really happening here... I''d really like to see a "cleaner" more concise version of all of this with just "standard" javascript (which of course proto is, but just provides great helper methods for us). myBase = Class.create(); myBase.prototype = { initialize: function(name) { //private variables var _myPrivateName = name + " Arooney Doony"; //public properties this.name = name; //private methods var _myNameIsJim = function() { return name == "Jim"; }; //public (instance/privileged) methods (only available to instances of this class and have full access to private members) //NOTE: I use Object.extend here simply to encapsulate these methods in one place (bulk applying via object notation looks cleaner to me) Object.extend(this, { sayHi: function(isOldBuddy) { if (isOldBuddy) alert("Heyyy, what''s up, it''s me... you know... you''re old pal, " + _myPrivateName); else alert("Hi"); }, //maintain class level scope for methods needing to access other instance members sayHiFromJim: function() { this.sayHi(_myNameIsJim()); }.bind(this) }); }, //instance (non-privileged) or static methods (cannot access private members and can optionally be accessed statically via the prototype of the object) //to enforce static vs. instance calls, you can apply an instanceOf check on the "this" object within the function, or have a global EnforceStatic system to handle that step elegantly, but again, for brevity''s sake I''ll forego that instanceIsNameJames: function() { return (this.name == "James"); }, staticIsNameJim: function(name) { return name == "Jim"; } }; //Now, create a subclass of which inherits from myBase. Inheritance applies to the prototype (static or non-privileged) members as well as to the constructed instance members (meaning I get all public members and parameterized construction of the base class is fully supported) mySubclass = Class.create(); Object.extend(Object.extend(mySubclass.prototype, myBase.prototype), { //first inherit at the prototype (static) level initialize: function(name) { //cache the superclass instance to retain access to it''s methods this.base = new myBase(name); //now, inherit the instance members Object.extend(this, this.base); //handle any method overrides desired now (example code purposely written only to demonstrate overriding with base class preservation) Object.extend(this, { sayHiFromJim: function() { if (this.instanceIsNameJames()) this.sayHi(true); else this.base.sayHiFromJim(); }.bind(this) }); } }); //base class demo new myBase("James").sayHiFromJim(); // "Hi" new myBase("Jim").sayHiFromJim(); // "Heyyy, what''s up, it''s me... you know... you''re old pal, Jim Arooney Doony" alert(myBase.prototype.staticIsNameJim("Jim")); // "true" //subclass demo new mySubclass("James").sayHiFromJim(); // "Heyyy, what''s up, it''s me... you know... you''re old pal, James Arooney Doony" new mySubclass("Jim").sayHiFromJim(); // "Heyyy, what''s up, it''s me... you know... you''re old pal, Jim Arooney Doony" new mySubclass("Bob").sayHiFromJim(); // "Hi" alert(mySubclass.prototype.staticIsNameJim("Jim")); // "true" On 7/20/06, Eric Anderson <eric-ANzg6odk14w@public.gmane.org> wrote:> > Ryan Gahl wrote: > > The beauty though, Eric, is that you can use prototype to achieve this > > as well. > > Of course you can do private properties when using prototype. The > support for doing so is provided by closures in the JavaScript language > so you can do that with any JavaScript framework. All I was saying is > that the YUI example given (which I am not familiar with) seems to > encourage this behavior. But you can implement it with any framework. I > don''t see prototype as helping you with this much. It is just part of > the language (behavior of closures). > > > prototype.js into and you''ll see it provides the means for a complete > > classical OO style, including private members, interfaces, enums, > > etc..., which greatly (greatly I say) improves code readability, re-use, > > refactorability, concern and behavior separation, etc... > > I will have to disagree with you on this point. Although doing private > properties can be done with Javascript (using closures) I don''t see > prototype as helping you with this any. The code example you gave below > seems quite unreadable to me (no offense, just my opinion of the > readability). Look at the loops that we are jumping through: > > > The trick is encapsulating the class definition as a whole inside the > > contructor method (using bind() to preserve the lexical scope of the > > containing class), > > Both of these actions seem very unfriendly to me. Having to define my > entire object inside the constructor? Appending a bind(this) to every > method I create? Private properties have questionable value if it is > easy to use. If I have to go through a lot of work the value does not > make up for the increased code complexity in my opinion. > > > which adds little to no overhead to instantiation > > since the methods would have to be created in memory anyway... > > It will add overhead because each instance of "myObject" will have it''s > own property instead of all instances accessing the property through the > prototype chain. Although the difference is so small nobody will know. :) > > This also bucks the system because people expect the prototype object to > define common methods instead of each object having it''s own reference > to the method. Normally I can do: > > myObject.prototype.publicMethod = function() { > // ... some implementation ... > } > > and expect that to redefine "publicMethod" for all instances of myObject > (already instantiated or not). But in this case I am defining the method > in the wrong location because the method is defined inside the > constructor removing the ability to redefine prototype properties. > > > Exactly, Eric, and it does so with tremendous success. There are many > > advantages to classical OO, and proto gives you that, plus you always > > have the underlying prototype system of js if you want it (2 OO > > paradigms at your disposal, wonderful!). > > I agree that having both systems at your disposal is good. From what I > have heard the "standards people" (whoever they are) are looking to add > real classes to EMCAScript soon (and ActionScript which I believe is > EMCAScript compliant has already done that) so I think many others would > agree both systems are good. > > But I disagree that prototype does it will tremendous success. I > consider the class-based OO emulation adequate but not elegant. It was > approaching elegant when "extend" extended Object.prototype but of > course that broke language conventions so it had to be moved to "Object" > which was less elegant. From what I have read Sam Stephenson is not > really happy with the current class-based OO emulation. See: > > http://sam.conio.net/ > > Specifically "Prototype''s class system is definitely experiencing > growing pains" and "You can expect Base to make its way into Prototype > 2.0 in a form that''s backwards-compatible with Class.create and > Object.extend." indicates to me that the current system (Class.create > and Object.extend) is not considered ideal. > > I think having some sort of class-based OO emulation is good but I would > hardly call the current implementation a tremendous success. It is > adequate and the rest of prototype/scriptaculous rocks so much that we > still use prototype with enthusiasm. But I think many people will be > happy to get a more elegant system in place. > > Just my opinion > > Eric > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Thank you all guys! as a developer, im so lucky to be in this list. more power to this list! _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs