Minimalist Classes

Brendan Eich brendan at mozilla.com
Wed Nov 2 11:00:25 PDT 2011


On Nov 2, 2011, at 10:35 AM, David Bruant wrote:

> Le 02/11/2011 18:09, Brendan Eich a écrit :
>> On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
>> 
>>> Another topic:
>>> -----
>>> class Monster {
>>> 
>>>  private name, health;
>>> 
>>>  sameName(other) {
>>>    return @name === other at name;
>>>  }
>>> }
>>> -----
>>> I am under this impression that you are accessing the private property ("other at name") of an instance which isn't you (other !== this) and I'm not sure it's a good idea.
>> Private names do not leak via reflection, not even via proxies. So what's the problem?
> My problem is that private names are per-class instead of per-instance.

See my reply to Kam. We're not sugaring instance-private ivars. I am proposing something we agreed to in Nov. 2008: sugaring class-private ivars.

You can make instance-private ivars yourself in the constructor using Name.create, and go to town. Knock yourself out! (I mean that in a good way, at least from where I sit :-P).


>>> Is "other" a monster? (how do you "recognize" a monster from any other object?).
>> You could do ad-hoc type or shape tests. For the example, and even in most cases in general, there's no need. Duck typing works with private names too.
> Who is "you" in your case? My "you" was "runtime". I think runtime
> shouldn't do heuristic-tests like comparing shapes.

We don't have types. I have no idea what you are proposing, but my point stands: there's no need to recognize another Monster and no capability leak. The code works as much JS today does with public property names.

/be



More information about the es-discuss mailing list