On Feb 19, 2008 10:21 AM, liorean [EMAIL PROTECTED] wrote:
On Feb 18, 2008 1:17 PM, liorean [EMAIL PROTECTED] wrote:
On 19/02/2008, Garrett Smith [EMAIL PROTECTED] wrote
(o.f)(); // =o
This should be window.
No it shouldn't. The grouping syntax specifically doesn't call
GetValue
On Feb 18, 2008 1:17 PM, liorean [EMAIL PROTECTED] wrote:
Basically the idea was along the lines of investigating the effects of
removing GetValue usage from those productions whose semantics just
pass values through (such as all the shortcut evaluation operators,
parenthesised
[Maciej's latest message is a continuation of the following thread. I have
removed email addresses from the correspondence below to avoid helping
spammers. This conversation took place on e-TC39 -at- ecma-international.org
]
Forwarded conversation
Subject: ES3.1 Proposal Working Draft
[Another recent discussion on e-TC39 -at- ecma-international.org. This one
started as an administrative discussion. I have removed the administrative
bits and left those of potential general interest. Since the thread is here
all gathered together, I have also removed the parts where one message
Each of us has some pet addition we think would be a great addition to
the language. const, decimal, getters and setters, destructing
assignment -- all these have come up just this morning!. Each of these
makes the language larger and more complex, imposing a general diffuse
cost on everyone.
2008/2/20 Adam Peller [EMAIL PROTECTED]:
Mark, as I recall, the discussion at the March meeting in Newton involved
implementing decimal arithmetic in ES3.1 to *replace* the floating point
implementation in ES3, thus no new syntax. Yes, this would have unexpected
results for those who actually
On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
Is there any way this compatibility can be mitigated? I am assuming
there is
no conceivable way to actually replace methods ad-hoc with arbitrary
functions and retain sane typing and class expectations.
I'm not sure why you assume this. Latest
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote:
Each of us has some pet addition we think would be a great addition
to
the language. const, decimal, getters and setters, destructing
assignment -- all these have come up just this morning!. Each of
these
makes the language larger and
On Feb 20, 2008, at 1:00 PM, Adam Peller wrote:
Each of us has some pet addition we think would be a great
addition to
the language. const, decimal, getters and setters, destructing
assignment -- all these have come up just this morning!. Each of
these
makes the language larger and more
On 2008-02-20, at 17:20 EST, Brendan Eich wrote:
On Feb 20, 2008, at 10:17 AM, Kris Zyp wrote:
Is there any way this compatibility can be mitigated? I am assuming
there is
no conceivable way to actually replace methods ad-hoc with arbitrary
functions and retain sane typing and class
On Feb 20, 2008, at 3:42 PM, Kris Zyp wrote:
I thought the question was about annotating class fixtures?
Yes, that was my intent, sorry I wasn't clearer.
No problem, sorry for assuming you meant ES3-compatible code.
I knew that built-ins were
designed to be backwards compatible. I don't
I thought the question was about annotating class fixtures?
Yes, that was my intent, sorry I wasn't clearer. I knew that built-ins were
designed to be backwards compatible. I don't have the RI in front of me at
the moment, but I assume you can't do replace a method on a user class with
another
Absolutely not with fixtures, but you can put the prototype qualifier in
front of function definitions in classes to create prototype methods just
like the ones in ES3's builtins, and you can make your class dynamic
(although IIRC, all class objects where static properties live are
At http://wiki.ecmascript.org/doku.php?id=ses:ses Doug Crockford
explains a rationale for a secure variant of EcmaScript, hereafter
ses. I am part of a team working on two such variants, Cajita and
Caja (Caja is mentioned on Crock's page. Cajita is a small ADsafe-like
subset of Caja). On the first
On Feb 20, 2008, at 4:21 PM, Kris Zyp wrote:
Of course a library function (like dojo.connect) that is called to
advise a
method on an object doesn't have control of how the object was
created. If
it is an instance of user class (and not dynamic), this function
will this
fail. This
Resending after adding myself to es4-discuss.
On 20/02/2008, Mark Miller [EMAIL PROTECTED] wrote:
[+es4-discuss]
On Wed, Feb 20, 2008 at 4:59 PM, Mike Samuel wrote:
On 20/02/2008, Mark Miller wrote:
Since a language is commonly defined as the set of strings produced by a
particular
There's a lot of implicit context here, some of which may be new to
es4-discuss readers. Also, not everything here is bound to become an
Ecma standard, as noted in mail I sent earlier today (3.1 could be a
TR and should be in the view of some on the TC39 committee). Comments
inline below,
Hi Brendan, thanks for the long and thoughtful answer. I think we have
many points of agreement.
I'll be responding to your message point by point soon. Tonight I'll
just mention a few that jumped out at me.
On Wed, Feb 20, 2008 at 7:35 PM, Brendan Eich [EMAIL PROTECTED] wrote:
Now we could
Graydon,
Thanks -- that helps to understand the status.
You are in a somewhat unique position having implemented more than any
other. Given Jeff's roadmap outline and the goal of weighing the
features against implementation experience -- which of the features that
you have implemented do you
Comments below:
Going further, I have mentally considered the language as providing 3
big categories of enhancement: fixtures, types, and namespaces. I
think that within -- and possibly between -- these groups there are
dependencies. For example, we can consider these levels of
Michael O'Brien wrote:
Graydon,
Thanks -- that helps to understand the status.
You are in a somewhat unique position having implemented more than any
other. Given Jeff's roadmap outline and the goal of weighing the
features against implementation experience -- which of the features that
21 matches
Mail list logo
