Some questions about Private Name Objects
Dean Landolt
dean at deanlandolt.com
Thu Sep 13 10:46:33 PDT 2012
On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson
<erik.arvidsson at gmail.com>wrote:
> On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith <khs4473 at gmail.com> wrote:
> > 1) Is method name-collision a practical problem, or just a theoretical
> > problem? If it's just a theoretical problem, then we don't need unique
> > names, and in teaching the language we can simply guide users away from
> > trying to create "private methods". In fact, without supporting syntax
> it's
> > unlikely that users would even bother trying to create them in the first
> > place.
>
> Yes. This is a real problem.
>
> It is a common problem that we see a lot with "private" members using
> naming conventions.
>
> class Base {
> constructor() {
> this._element = ...;
> }
> }
>
> class Derived extends Base {
> constructor() {
> this._element = ...; // OOPS!
> }
> }
>
Another good example where this is a problem is on prototype chains, a good
example of which you parenthetically noted (iterators). With unique names
it becomes feasible to hang any properties and methods you want off of
prototypes without worrying about collision. For instance, imagine an
persistance lib with a Record.prototype.save method:
var rec = new Record({ save: 'whoops' });
rec.save() // TypeError: Property 'save' is not a function
And thus we all fall back to the lovely Record.prototype.save.call(rec)
pattern. Unique names neatly sidestep this, giving us back our prototype
chains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120913/df2f406e/attachment.html>
More information about the es-discuss
mailing list