New private names proposal

[David Flanagan]

On 12/22/2010 09:57 AM, Allen Wirfs-Brock wrote:
> I think there are some interesting ideas to explore in both D.
> Flanagan's proposal and D. Herman's variations upon it. However, they
> both seem to be ignoring the second primary use case that I identified:
> conflict-free extensions of build-in or third party objects. While
> naming conventions or a sigil seems to be satisfactory to many as a way
> to implement "weak encapsulation". I don't think it works for the
> extension case.
>

Having to use # or [] to identify a private extension method would make 
those extensions too ugly for common use, I suppose.  I can't help 
thinking that what you're trying to propose is a kind of poor-man's 
private namespace.  I don't know what the problems with ES4 namespaces 
were nor how the current proposal avoids them.

In a subsequent message, Allen also wrote:

> I don't see why
>    private foo;
> is any more or less generative than:
>    var captured;
> or
>    function inner() {};
>
> They are all are declarative forms and all implicitly generate new runtime entities each time they are evaluated.
>

I've now realized that I don't actually object so much to the generative 
nature of private.  What bugs me is that it essentially declares a 
meta-identifier that is then used as if it were a regular identifier. It 
is the meta-mismatch that I have a problem with.

If "private foo" declared a meta identifier <foo>, and I could then 
write o.<foo>, that would make sense to me.  But of course, that syntax 
is more cumbersome than just using square brackets.

It feels to me as if the private declaration is behaving like a macro.

Are there precedents for this kind of meta-identifier in other languages?

	David