Sorry iPad autocorrection strikes again... The comment towards the bottom should read: > I was attempting to keep as close as possible to the terminology used in the > proposal.
On Jun 8, 2011, at 3:41 AM, Kam Kasravi <kamkasr...@yahoo.com> wrote: > > > On 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). > > This was related to Peter's concern included below for brevity > >>>> Based on my understanding of what the desugared code would be, the >>>> last line above would be an error because Dragon.allMonsters is >>>> undefined. > > I was wondering if this could be solved in some way without explicitly > referencing the particular Constructor. This isn't a static private issue per > se, rather a suggestion for an operator that would allow one to reference > Monster.allMonsters as Dragon.allMonsters. eg static(Dragon).allMonsters. > Although it would probably be more consistent to resolve Dragon.allMonsters > in the same way properties on the prototype chain are resolved. So we can > probably ignore this suggestion. > >> >> 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. > > Yes, I agree, I was attempting to keep as close as possible to http > terminology used in the proposal. > >> >> On another topic, it does seem like "protected" is inevitable, doesn't it? > > Which may be a slippery slope :( BTW is it premature to ask questions on > harmony proposals in their current state? > >> >> /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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
