On 2008-08-25, at 17:26EDT, Kris Zyp wrote:
> This why I would like to ensure that class sugar also used a
> prototype-based model, so existing class structures are compatible
> with the new syntax.
[Late to the party..., perhaps the dishes have already been cleared?]
Me too. If classes are
If you take the subject and event example and scale that up ten fold
so that the object has 20 methods instead of 2 the code quickly
becomes hard to maintain and the size over the wire increases quickly.
I think what Ihab said points this out clearly and without a good
forwarding mechanism ZI seem
On Mon, Aug 25, 2008 at 7:15 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> No, prototypes are here to stay. There's even Object.create to
> relieve prototypers from having to write constructor functions.
>
> The desire to explore ZI is two-fold:
>
> 1. It may help the committee to see the smallest
Fwiw --
On Sat, Aug 30, 2008 at 12:58 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
> >From http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html :
> ... he explained that the real problem wasn't classes per se, but
> rather implementation inheritance (the extends relationship).
> Inte
On Mon, Aug 25, 2008 at 7:15 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> No, prototypes are here to stay. There's even Object.create to
> relieve prototypers from having to write constructor functions.
>
> The desire to explore ZI is two-fold:
>
> 1. It may help the committee to see the smallest
2008/8/25 Brendan Eich <[EMAIL PROTECTED]>:
> On Aug 25, 2008, at 7:07 PM, Erik Arvidsson wrote:
>
>> I've been quiet on these threads for a long time but i just wanted to
emphasize Kris's point. Whatever we decide to desugar the class syntax into
I think it is very important to get this right. We
On Aug 25, 2008, at 7:07 PM, Erik Arvidsson wrote:
> I've been quiet on these threads for a long time but i just wanted
> to emphasize Kris's point. Whatever we decide to desugar the class
> syntax into I think it is very important to get this right. We need
> to make classes work with exist
2008/8/25 Kris Zyp <[EMAIL PROTECTED]>:
>
>
> A lot of Ajax widgets, e.g. Dojo, use their own inheritance models, often
based on copying properties (sometimes based on prototypes; in the case of
Dojo's MI, both!). Copying is fine for a zero-inheritance classes-as-sugar
proposal. The prototype stuff
On Mon, Aug 25, 2008 at 5:23 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2008, at 4:57 PM, Peter Michaux wrote:
>> I think the ability to have two modules in one file means modules will
>> need to name themselves. That is they will need to be declared with a
>> name like
>>
>> module f
On Aug 25, 2008, at 4:57 PM, Peter Michaux wrote:
> There needs to be a way(s) to distinguish which variables have which
> lifetimes and visibilities.
We have ways already: explicit blocks containing let-declared
temporaries; your public to make things visible outside their lexical
scope.
Ru
On Mon, Aug 25, 2008 at 2:01 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2008, at 12:23 PM, Peter Michaux wrote:
> > Now there is another problem: differentiating between which
> > variables are local to the constructor function (that is,
> > transient and garbage collected after the
A lot of Ajax widgets, e.g. Dojo, use their own inheritance models, often
based on copying properties (sometimes based on prototypes; in the case of
Dojo's MI, both!). Copying is fine for a zero-inheritance classes-as-sugar
proposal. The prototype stuff, as Kris points out, is different.
T
On Aug 25, 2008, at 12:23 PM, Peter Michaux wrote:
To refer to the instance in the sugared language, and there are valid
use-cases for doing so, we should use |this|. There's no point in
introducing a new keyword.
If there is a need to refer to the instance then "this" does make
sense. What wo
On Mon, Aug 25, 2008 at 11:28 AM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 25, 2008, at 12:34 AM, Peter Michaux wrote:
>
>> On Sun, Aug 24, 2008 at 9:44 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>>
>>> Desugared from:
>>
>>> class Point {
>>> private var x = Math.random();
>>> function getX
On Aug 25, 2008, at 6:39 AM, Kris Zyp wrote:
>>> I am surprised this is up for debate, I would also think that we
>>> would
>>> want
>>> instance-private by default.
>>
>> We can debate lots of things, some that might actually be in
>> play. AFAIK
>> this one is not decided in the committee
On Aug 25, 2008, at 12:34 AM, Peter Michaux wrote:
> On Sun, Aug 24, 2008 at 9:44 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>
>> Desugared from:
>
>> class Point {
>> private var x = Math.random();
>> function getX(){
>> return this.x;
>> }
>> ...
>> }
>
> Is there any need for the "th
>> I am surprised this is up for debate, I would also think that we would
>> want
>> instance-private by default.
>
> We can debate lots of things, some that might actually be in play. AFAIK
> this one is not decided in the committee (it's way too early), but IP
> does have some strong propon
On Sun, Aug 24, 2008 at 9:44 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> Desugared from:
> class Point {
> private var x = Math.random();
> function getX(){
> return this.x;
> }
> ...
> }
Is there any need for the "this."? Some languages allow "this.x" to
get out from under the shado
On Aug 24, 2008, at 9:44 PM, Kris Zyp wrote:
> I am surprised this is up for debate, I would also think that we
> would want
> instance-private by default.
We can debate lots of things, some that might actually be in play.
AFAIK this one is not decided in the committee (it's way too early),
On Aug 24, 2008, at 8:40 PM, Peter Michaux wrote:
>> Polls are not so good, compared to reasons. Could you give your
>> rationale
>> and talk about the trade-offs, in your experience?
>
> You summed it up nicely with the hat trick:
>
> "It's a nice hat trick: privacy, higher integrity, and seman
> On Sun, Aug 24, 2008 at 5:10 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
>> [...] I believe it is still possible to emulate private instance
>> variables with prototypes (although much more awkward than with a
>> "private"
>> attribute). I could demonstrate if desired.
>
> I desire. Please do. Thank
On Sun, Aug 24, 2008 at 7:41 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 24, 2008, at 7:36 PM, Peter Michaux wrote:
>
>> On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich <[EMAIL PROTECTED]>
>> wrote:
>>> On Aug 24, 2008, at 4:09 PM, Mark S. Miller wrote:
>>
>> [snip]
>>
>>> Others on this lis
On Sun, Aug 24, 2008 at 8:40 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
> setInterval(s.fire(), 24*60*60*1000);
minus the parens after "fire"
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[order restored]
On Sun, Aug 24, 2008 at 7:41 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
>
> On Aug 24, 2008, at 7:36 PM, Peter Michaux wrote:
>
>> On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
>>>
>>> On Aug 24, 2008, at 4:09 PM, Mark S. Miller wrote:
>>
>> [snip]
>>
>
Polls are not so good, compared to reasons. Could you give your
rationale and talk about the trade-offs, in your experience?
/be
On Aug 24, 2008, at 7:36 PM, Peter Michaux wrote:
> On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich <[EMAIL PROTECTED]>
> wrote:
>> On Aug 24, 2008, at 4:09 PM, Mark
On Sun, Aug 24, 2008 at 6:05 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
> On Aug 24, 2008, at 4:09 PM, Mark S. Miller wrote:
[snip]
> Others on this list should comment on class-private vs. instance-
> private.
If this is just a poll then I'm all for instance-private.
Peter
___
On Aug 24, 2008, at 4:09 PM, Mark S. Miller wrote:
> This gives
> instance-private rather than class-private variables, which is the
> safer default for a dynamic language. The new objects-as-closure sugar
> also gives instance-private encapsulation, and without proposing any
> new semantic state.
On Sun, Aug 24, 2008 at 5:10 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> [...] I believe it is still possible to emulate private instance
> variables with prototypes (although much more awkward than with a "private"
> attribute). I could demonstrate if desired.
I desire. Please do. Thanks.
--
>> I don't see why it is better to have classes be sugar for closured object
>> literals rather than prototype based structures. It seems the benefits
>> that
>> are being sought after are auto-binding on method extraction and private
>> method creation.
>
> I'm not sure what you mean by "private
On Sun, Aug 24, 2008 at 3:22 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> I don't see why it is better to have classes be sugar for closured object
> literals rather than prototype based structures. It seems the benefits that
> are being sought after are auto-binding on method extraction and private
>
I don't see why it is better to have classes be sugar for closured object
literals rather than prototype based structures. It seems the benefits that
are being sought after are auto-binding on method extraction and private
method creation. Both of these can be attained with prototype-based class
On Tue, Aug 19, 2008 at 9:15 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> Why do you freeze the functions? Is this just to cater to mutable function
> critics, or is there actually a reason tied class semantics?
It is to cater to mutable function critics, since they're right ;).
--
Cheers,
--Mar
Allen Wirfs-Brock wrote:
> I thought it was Peter Deutsch who originally said "you can cheat if you
> don't get caught." regarding Smalltalk implementations
I think the source of the attribution to Ingalls is this paper:
The Smalltalk-76 Programming System - Design and Implementation
Daniel H. H.
> function Point(x, y) {
>const self = Object.create(Point.prototype, {
>toString: {value: Object.freeze(function() ('<' + self.getX()
> + ',' + self.getY() + '>'))},
>enumerable: true},
>getX: {value: Object.freeze(function() x),
>enumerable: true},
>
On Tue, Aug 19, 2008 at 6:47 PM, Dean Edwards <[EMAIL PROTECTED]> wrote:
> That code is ugly.
Yes indeed. That's why everyone agrees that this pattern needs some
syntactic sugar.
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
h
Mark S. Miller wrote:
>
>
>
> Point as a non-final non-abstract root/mixin class where toString is a
> final method:
>
> function PointMixin(self, x, y) {
> Object.defineProperties(self, {
> toString: {value: Object.freeze(function() ('<' + self.getX()
> + ',' + self.getY() + '>'))}
ugust 19, 2008 6:03 PM
> To: Michael Daumling
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; TC39; es3.x-
> [EMAIL PROTECTED]
> Subject: Re: Look Ma, no "this" (was: ECMAScript Harmony)
>
> On Tue, Aug 19, 2008 at 5:54 PM, Michael Daumling <[EMAIL PROTECTED]>
>
I sure did. Sorry for the noise.
Michael
-Original Message-
From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2008 6:03 PM
To: Michael Daumling
Cc: Peter Michaux; [EMAIL PROTECTED]; [EMAIL PROTECTED]; TC39;
[EMAIL PROTECTED]
Subject: Re: Look Ma, no "this&
On Tue, Aug 19, 2008 at 5:54 PM, Michael Daumling <[EMAIL PROTECTED]> wrote:
> Just a side note: The code below would create three Function objects per
> Point instance. Some may argue that the days of having little memory are
> long gone, but we still have small devices plus a garbage collector th
Just a side note: The code below would create three Function objects per
Point instance. Some may argue that the days of having little memory are
long gone, but we still have small devices plus a garbage collector that
may need to iterate through live objects, including three Function
objects per P
40 matches
Mail list logo
