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@name;
>>> }
>>> }
>>> -----
>>> I am under this impression that you are accessing the private property
>>> ("other@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
