> > Kangax's point might be moot for simple constructors, but that doesn't > make it "plain wrong". Suppose you have a constructor with 100 > methods and you want 100 instances, is it better to define each and > every method on each and every instance, or put them on the > constuctor's prototype? More simply, would you consider it OK to > create 10,000 function objects when 100 will do the job?
That's one of those irrelevant, contrived examples of something you'll never see in a full blown real life application. Even then, you just will not see a significant slowdown. Yes, if you, for some reason other than running an ill conceived test, create 10,000 functions at once, you're not making optimal use of memory. Your example assumes 100 instances of the same class (that for some reason has 100 functions??) are ever going to exist, which just will not happen unless you are talking about one of the worst architects on the planet, and once again no use of shared memory tactics will save that project from failure. Please keep in mind I'm not talking about things like "HtmlElement". I'm talking about application classes. If you are unequivocally right, then Prototype.js should stick with > the strategy employed for IE of adding methods to every DOM element it > encounters as there would be no point in extending HTMLElement > instead. You guys are confusing what I'm saying. Kangax said encapsulating private/public, instance only members within the constructor is bad design and HE is the one that said this without considering that what he was saying was not categorically correct. I simply jumped in to defend the pattern as a sound and scalable approach to large scale application development, citing the merits of using it. (NOTE: once again, I am not saying that NOT using it is wrong or that your code is not good, simply defending the usage of it as not "bad design") I never once said Prototype, or you, or kangax, or the OP, should USE it compared to anything else. Much of the argument in this thread comes from the fact that > javascript doesn't have classes, or instance variables, or static > members: but there are various ways of emulating them. What you are > really arguing about are implementation preferences. Javascript does not have classes, true. Javascript does have instance variables, and does have static members (where in the world are you getting this stuff). You're kind of saying "javascript is not object oriented", which it is. Does javascript have instances? Yes, otherwise, what is this: "var blah = new Foo();"? Are the properties and methods that are unique to each instance called instance members? Yes. And what about those members that are shared across instances? What's another word for shared, in object oriented vernacular? Static. And what we're arguing about is the fact that kangax said that a perfectly good design pattern is bad. I said "no, that's wrong and here's why" If sound OO practice is bad design, than what do you make of the new features centered around these same concepts, that will be in Javascript 2? Concepts of good, bad, right and wrong are purely subjective That statement is wrong :) (sorry, had to do it) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
