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@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
