Re: RFC 188 (v1) Objects : Private keys and methods

   > This is an interesting proposal, but it seems to be missing
   > something, or maybe I am. It seems like once a single hash entry is
   > marked private, that it is then impossible to mark future entries
   > non-private...i.e. there is no corresponding unary "public"
   > function.

That's right. Perhaps it's too fascist. I'll think about it.

   > However, it seems that one side effect of achieving this is that
   > the hash of interest can no longer be used to present public data
   > of classes inheriting from it--they have no mechanism to add new
   > public data to the hash inherited from the superclass. While some
   > might argue that this is good, others might argue that it is bad,
   > and in the presence of such differing opinions, it certainly seems
   > like that choice should be left to the class author.

That can easily be achieved with a "public" keyword to parallel private.
   
   > The proposal also seems to leave somewhat unspecified what happens
   > to other existing non-private keys that were already in the hash at
   > the time the first private key was added. Do they continue to be
   > directly accessible via their names?

Yes. That's required to allow "private" to be used to extend pre-existing
classes cleanly.
   
   > Do they also get qualified with the package name?

No.
   
   > Is it an error
   > to insert a private key into a hash already containing
   > non-private keys?

...of the same name...yes.

I will make these clearer in the next version,

Thanks,

Damian