On Jun 8, 2011, at 12:57 PM, Bob Nystrom wrote:.
>
> Patterns like this have the advantage of supporting more than two interfaces.
> Where public/protected lets you define two windows, "to everyone" and "to my
> subclass", using composition to form those interfaces lets you define more
> fin
On Wed, Jun 8, 2011 at 11:50 AM, Allen Wirfs-Brock wrote:
> One of their main points is that the extensibility interface that a class
> exposes to subclasses should be treated as a distinct interface from the
> interface that the classes exposes to external clients.
>
This is an excellent insight
On Jun 8, 2011, at 9:55 AM, Brendan Eich wrote:
> On Jun 8, 2011, at 8:50 AM, Mark S. Miller wrote:
>
>> On Wed, Jun 8, 2011 at 8:27 AM, Brendan Eich wrote:
>>> Btw, in both C++ and Java, the semantics of "protected" is a mess, in
>>> different ways.
>>
>> Sure. Let's not make those mistakes.
On Wed, Jun 8, 2011 at 11:22 AM, Bob Nystrom wrote:
>
>
> On Wed, Jun 8, 2011 at 9:55 AM, Brendan Eich wrote:
>
>> We can definitely leave protected out. My "seems inevitable" was in
>> response to Kam bringing it up via a question that I expect will be
>> frequently asked.
>>
>
> I really hope
On Wed, Jun 8, 2011 at 9:55 AM, Brendan Eich wrote:
> We can definitely leave protected out. My "seems inevitable" was in
> response to Kam bringing it up via a question that I expect will be
> frequently asked.
>
I really hope we can. My interest in adding class syntax to JS was that I
saw the
On Jun 8, 2011, at 8:50 AM, Mark S. Miller wrote:
> On Wed, Jun 8, 2011 at 8:27 AM, Brendan Eich wrote:
>> Btw, in both C++ and Java, the semantics of "protected" is a mess, in
>> different ways.
>
> Sure. Let's not make those mistakes. Non-fixable in your view?
>
>
> Not necessary in my view
Mark Miller wrote
> 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.
>
Aren't there als
On Wed, Jun 8, 2011 at 8:27 AM, Brendan Eich wrote:
> Btw, in both C++ and Java, the semantics of "protected" is a mess, in
> different ways.
>
>
> Sure. Let's not make those mistakes. Non-fixable in your view?
>
>
Not necessary in my view. There are all sorts of old constructs that address
needs
On Jun 8, 2011, at 8:14 AM, Mark S. Miller wrote:
> 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
On Jun 8, 2011, at 3:41 AM, Kam Kasravi wrote:
> 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.allMonste
On Wed, Jun 8, 2011 at 3:41 AM, Kam Kasravi wrote:
>
> Which may be a slippery slope :( BTW is it premature to ask questions on
> harmony proposals in their current state?
>
Hi Kam, not at all. Such questions are welcomed, and will provoke us to
clarify these proposals quickly. Thanks.
--
On Wed, Jun 8, 2011 at 3:05 AM, Brendan Eich 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.
>
>
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 wrote:
>
>
> On Jun 8, 2011, at 3:05 AM, Brendan Eich wrote:
>
>> On Jun
On Jun 8, 2011, at 3:05 AM, Brendan Eich 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://wi
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
Just as the private(this) is used to expose the private instance record, 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())
Regarding the
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 wrote:
>> Based on my understanding of what the desugared code would be, the
>> last line above would be an error because Dragon.allMonsters is
>
On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote:
> On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux 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
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux 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
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
> Are static members inherited? What happens in the last line of the
> following code?
>
>class Monster {
>static allMonsters = [];
>
>constructor() {
>Monster.allMonsters.push(this);
>}
>}
>
>clas
Are static members inherited? What happens in the last line of the
following code?
class Monster {
static allMonsters = [];
constructor() {
Monster.allMonsters.push(this);
}
}
class Dragon extends Monster {
constructor() {}
}
new M
21 matches
Mail list logo
