> 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
