Just have remembered that Python has doc string, so it's not actually a
comment. Is the problem about using comment for such purposes in parsing
procedure? (that it ignores whitespace and comment tokens)
On Mon, May 11, 2009 at 7:24 AM, Dan Tsimbala slip77...@gmail.com wrote:
On the other hand,
It seems that ES5 throws a TypeError for constructs like
Array.prototype.pop.call(abc)
whereas current implementations (and, I think ES3, but I didn't check
that closely) will return c.
Is this change intentional? There seems to be a note in the
compatibility appendix that is about a
The old behavior is indeed needed for web compatibility. All Array
methods are supposed to be generic and I know js libraries use them
heavily on NodeLists and ther non Array objects.
ES5, 15.4.4.6, has no type check by itself but it is calling
[[ThrowingPut]] which will throw when called on a
(Targeted replies below, too much to digest in one pass. :-P)
On May 8, 2009, at 8:49 PM, Kris Kowal wrote:
(function (require, exports) { + text + /**/\n}
Nit-picking a bit on names: require : provide :: import : export -- so
mixing require and export mixes metaphors. Never stopped me
Agreed, this is a problem.
Which compatibility appendix item did you think might apply? None of them were
intended to cover this situation.
Allen
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of James Graham
Sent: Monday, May
The motivation for replacing [[Put]] and [Delete]] calls with throwing versions
in the Array prototype functions was to provide proactive notification when
these algorithms were applied to arrays (or other objects) where the existence
of non-writable properties might result in violations of the
On Mon, May 11, 2009 at 11:47, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
The motivation for replacing [[Put]] and [Delete]] calls with throwing
versions in the Array prototype functions was to provide proactive
notification when these algorithms were applied to arrays (or other
On Mon, May 11, 2009 at 8:40 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
The old behavior is indeed needed for web compatibility. All Array
methods are supposed to be generic and I know js libraries use them
heavily on NodeLists and ther non Array objects.
ES5, 15.4.4.6, has no type
-Original Message-
From: Erik Arvidsson [mailto:erik.arvids...@gmail.com]
...
I think the right solution would be to use a non throwing [[Put]] for
the Array methods for backwards compatibility. NodeList and Arguments
are the common array like structures that people use the array
generics
On May 11, 2009, at 1:26 PM, Mark S. Miller wrote:
[1] To the extent that we also wish to be compatible with
browser-specific content, since most browser instances are IE,
Note that right now, as IE8 is pushed via Windows Update and takes
over IE7's share, Firefox 3 / Gecko 1.9 moves to the
On May 11, 2009, at 1:54 PM, Brendan Eich wrote:
On May 11, 2009, at 1:26 PM, Mark S. Miller wrote:
[1] To the extent that we also wish to be compatible with
browser-specific content, since most browser instances are IE,
Note that right now, as IE8 is pushed via Windows Update and takes
TobyMurray wrote:
Hi caja folks,
I expect you're all aware of this but I wanted to mention a paper I
recently came across.
There is some really interesting formal work being done on secure
[subsets] of JavaScript. The paper whose title is the subject of this
post is particularly relevant
On May 11, 2009, at 3:14 PM, David-Sarah Hopwood wrote:
can be accessed implicitly. However no 'toNumber' property is
mentioned anywhere in the ECMAScript specs, and I don't know of
any implementation-specific property of that name. Have I missed
something, or is 'toNumber' a figment of the
On Mon, May 11, 2009 at 9:26 AM, Brendan Eich bren...@mozilla.com wrote:
On May 8, 2009, at 8:49 PM, Kris Kowal wrote:
(function (require, exports) { + text + /**/\n}
Nit-picking a bit on names: require : provide :: import : export -- so
mixing require and export mixes metaphors. Never stopped
On May 11, 2009, at 4:10 PM, Kris Kowal wrote:
I agree about mixing metaphors. The befuddlement of start : stop ::
begin : end is one that bothers me a lot. The notion is to desugar
import and export to these two facets, importing and exporting.
imports : exports would be proper, but doesn't
Kris Kowal wrote:
On Mon, May 11, 2009 at 9:26 AM, Brendan Eich bren...@mozilla.com wrote:
On May 8, 2009, at 8:49 PM, Kris Kowal wrote:
(function (require, exports) { + text + /**/\n}
Nit-picking a bit on names: require : provide :: import : export -- so
mixing require and export mixes
16 matches
Mail list logo
