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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
