> > It's obviously a matter of priorities. For me, performance is usually > one of the key factors. Simulating "private" properties (in a highly > dynamic language) does not compensate for the decreased speed.
But, there is no decreased speed noticeable, is what I'm saying. So you're sacrificing nothing to gain the benefits of private members, with public accessors. And, it's not a "simulation" -- adding an underscore and calling it private is closer to simulation. What I'm talking about is TRUE public vs. private exposure. There is nothing simulated about it. Doesn't really matter how we call it : ) > Having bunch of logic in constructor is not a good design (in my > experience) You're experience is wrong here, if it tells you that implementing instance only members, and truly private members, is not good design. It's an extremely valuable pattern, with very clear benefits. Your way is another pattern, with its own benefits. In MY experience (building massive single page high performance RIAs for large clients)... the benefits of projecting the long used classical OO paradigm (which as we all know is really one of the points of Prototype.js) into javascript far outweigh the (completely unnoticeable) performance issues. The assignment of a series of properties and methods within a contructor is NOT the same as the processing that those methods eventually do when they get called. You will never see a difference in performance in a live application. You can run some wildly inaccurate "create a million instances" side by side tests... and still only see a minor difference. Your claims simply have no basis, and it really is borderline FUD. Even assigning a member via a constructor function's prototype is technically not instance only, because of the simple fact that it sill possible to access the member statically be doing "someClass.prototype.doSomething()". YES, I know this is not a real issue, because not many (smart) people will be calling methods directly against the prototype object... but does illustrate what I mean by TRULY instance-only. For more information: http://www.someelement.com/2007/03/multiple-inheritance-with-prototypejs.html About half way down I explain a little more about what I mean by "truly instance-only" vs "prototype-static". It's most definitely a major departure from how most js devs think. But, again, in MY experience, there are very real long term benefits to this approach, all centered around code longevity and maintainability across the diversely distributed skill levels of team members.... and almost NO downside. On Wed, Jul 2, 2008 at 2:10 PM, kangax <[EMAIL PROTECTED]> wrote: > > > > On Jul 2, 1:12 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote: > > > Of course there are. To say otherwise is confusing. > > I'm not sure I understand what you mean, Ryan. > JavaScript doesn't have a notion of "static" (except for a reserved > keyword that's not even implemented). There are "direct" members and > members shared via object's [[Prototype]]. Since prototype.js > simulates "classes" a reasonable definition of static would be: > properties of a Function object created via Class.create. The way > Antoine put it sounds confusing to me (and I'm sure to other folks as > well) > > > You could do that, though "fat" constructors is usually not a good > > > > > idea. It would also cripple performance if constructor is called > > > frequently. > > > > Not true at all. "fat" constructors? Let's not make up FUD terms here :) > > > > Doesn't really matter how we call it : ) > Having bunch of logic in constructor is not a good design (in my > experience) > > > The truth is, defining methods and properties from within the constructor > is > > the ONLY way to achieve truly instance only members, and the only way to > > "instance only" members could be easily created by assigning functions > to properties of object's prototype. I don't see a need for > constructor. > > > create truly private/public members on the instance (instead of people > just > > adding an underscore character to a public member and calling it > private). > > > > For 95% of classes, there will be no noticeable performance issues. > > It's obviously a matter of priorities. For me, performance is usually > one of the key factors. Simulating "private" properties (in a highly > dynamic language) does not compensate for the decreased speed. > > -- kangax > > > -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-920-574-2218 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
