On 7/20/06, Ryan Gahl <[EMAIL PROTECTED]> 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}.bind(this)
privateFunction1();
>> snip:
>> What Prototype is trying to do here is trying to simulate class-based OO
>> on top of the built-in prototype-based OOExactly, 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 < [EMAIL PROTECTED]> 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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________ Rails-spinoffs mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
