On Wed, Jun 8, 2011 at 3:05 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Jun 8, 2011, at 2:45 AM, Kam Kasravi wrote: > > Just as the private(this) is used to expose the private instance record, > > > Please read > > private(this), e.g., is > > - unbearably verbose; > - leaks an implementation detail. > > from http://wiki.ecmascript.org/doku.php?id=harmony:classes#open_issues. > > The syntax is a placeholder. It will not last. > > > could static([[Constructor]]) be introduced to provide access to the union > of static properties across the set of constructor objects? (I know that > their is some concern about the lengthy syntax of private()) > > > It's not "concern", it is an open issue to resolve by using better syntax. > > What does "union of static properties across the set of constructor > objects" mean? We're not reifying sets of properties as objects, if that's > what you mean (static private yikes). > > I can see how private(foo) brings this to mind. This is the problem I > clumsily labeled "leaks an implementation detail". > > > Regarding the use of private(AssignmentExpression), does it provide access > to all private ExportableDefinition's regardless of what inherited class > they were declared in? That is given > *class Monster { * > * constructor(health) { * > * private health = health; * > * }* > *} * > * > * > *class GilaMonster prototype Monster { > constructor(owner) { * > * super(10); * > * private owner = owner;* > * }* > * eat(critter) { * > * If(critter === private(this).owner) {* > * private(this).health = 0; * > * } else {* > * private(this).health++;* > * }* > * }* > *}* > > Should the GilaMonster's private record include health? > > > The "private record" especially views as an "object" is a kind of > placeholder too. It doesn't help to think of it as a record. It probably > does not help to think of it as an object, either, especially if you cannot > get at it via anything like the still-straw private(this) or private(other) > syntax. > > On another topic, it does seem like "protected" is inevitable, doesn't it? > Actually, it isn't another topic. It's why Kam's GilaMonster cannot see Monster's "health". "private" means "private to the class", not "private to the class and subclasses". "protected" would mean the second, and no, I don't think it's inevitable. E and Caja have been doing very well with "private", "public", and inheritance, and I've only ever been frustrated by the lack of "protected" once in a blue moon. And it was always easy to work around its absence. Given ES-next's private names and weak maps, it becomes even easier to work around the absence of "protected". Btw, in both C++ and Java, the semantics of "protected" is a mess, in different ways. > > /be > > > > On Jun 6, 2011, at 11:08 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> > wrote: > > > On Jun 6, 2011, at 10:32 AM, Brendan Eich wrote: > > On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote: > > > On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux <petermich...@gmail.com> > wrote: > > Based on my understanding of what the desugared code would be, the > > last line above would be an error because Dragon.allMonsters is > > undefined. > > > That's correct. Do you have any examples of code where inheriting the > constructor objects would be helpful? > > > Used all the time in Ruby, and in some Smalltalks. Supported by > CoffeeScript. See > > > Actually, all modern Smalltalks where modern means anything post 1980 > > > > > > https://gist.github.com/1007150 > > https://gist.github.com/1006999 > > > (warning: Ruby reading skills required). > > > /be > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
