es-discuss Digest, Vol 46, Issue 22

thaddee yann tyl thaddee.tyl at
Tue Dec 21 14:52:11 PST 2010

I was very interested when I heard about private names. It seems like
a very good idea. However, the specification that the strawman gives
is harder than I thought it would be.

I am unsure I fully understand this _private names_ proposal.

For starters, what is the "scope" of private names?

private name;
var obj = {}; = 5;  // We want obj to have a Private Name value.
// ... Later on ... (here, we should do something so that the
following lines work).
var foo = {}; = {name:'foo'};  // Here, we would like foo to have a
property "name" whose value is an object whose name property holds the
value "foo".
// How to do so? Is foo['name'] = {'name':'foo'}; unavoidable; does it
even work?
// Is {name:'foo'} going to contain a Private Name, or rather a
property (which is what we want)?

Secondly, I am trying to understand what this code does, too:
a = {};
k = {a: a};
a['k'] = k;

function aa(o) {
  private a;
  k.a = o;  // Does it "override" the fact that a is a property?
  a.a = a.k.a;
  return #.a;

var a1 = aa(a);
var a2 = aa(a);  // Does it return the same thing?
print(a1 === a2);
print(typeof a2);
print(a[a2] === a.k.a);

On Tue, Dec 21, 2010 at 9:29 PM,  <es-discuss-request at> wrote:
> I am not sure what point you are referring to. Do you mean
> 1) Allow JavaScript programmers, who choose to do so, to manage the direct
> accessibly of object *properties*.  This may mean limiting access to methods
> of a particular instance, or to methods of the same "class", or to various
> friends or cohorts, etc.
> ? Other than terminology, I don't see how the proposals differ in this
> regard. If the issue is that we call the new state "<adjective> properties"
> so that it seems more familiar, fine.
>> and your argument concerning the second point is based upon an assumption
>> that I don't share regarding a particular "defensive programming" style.
> What assumption is that? If the assumption in question is whether "everyone"
> agrees that defensive programming should be "the norm", then I don't share
> that assumption either.
> --
>    Cheers,
>    --MarkM
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <>
> ------------------------------
> _______________________________________________
> es-discuss mailing list
> es-discuss at
> End of es-discuss Digest, Vol 46, Issue 22
> ******************************************

More information about the es-discuss mailing list