On Jul 2, 3:36 pm, "Ryan Gahl" <[EMAIL PROTECTED]> wrote:
> > 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 : )
I should have been more specific about performance decrease. Speed of
constructor execution has little to do with it. What matters is that
instances don't share methods via their prototype chain. Instead they
carry them as direct members. This leads to an increased memory
footprint and means that instead of O(1) you get O(N). Clearly there
are benefits : ) I find "true" private members (as you call them) of
little necessity when it comes to encapsulation. JavaScript is a
prototypal language. Members are meant to be shared via prototype
chains. Having common conventions like underscored names is a much
more efficient approach (in my experience).
>
> > 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-prototyp...
>
> 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.
>
My goal was not to go into discussion of "truly" private members
pattern. I know exactly which benefits come with it and I'm glad it
works for you. JavaScript happens to be designed in such way that
"truly" private members (as we know them) destroy one of its main
concepts. This has little to do with general usefulness of
encapsulation patterns and - yes - it does have real life performance
implications. I would appreciate if my reasonings weren't claimed to
be "FUD" : )
Best,
kangax
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
