brendan at mozilla.com
Wed Jan 14 15:48:08 PST 2009
It's because ES1-3.1 use [[Class]], e.g., for internal property
names, and the "semantic brackets" are also trac wiki syntax.
One fix is to write trac plugins (Python scripts) to make these ECMA
[[Foo]] names format nicely. I'm nowhere near enough of a trac guru to
try this. Volunteers?
On Jan 14, 2009, at 3:22 PM, Mark S. Miller wrote:
> When I look at some trac tickets, I see a red box with an error
> message instead of expected text. For example, the first comment at <http://bugs.ecmascript.org/ticket/428
> >, cut-n-pasted into my email is:
> Changed 1 month ago by brendan ¶
> At the Kona meeting, I thought we agreed to avoid making an array
> (say from another frame) indistinguishable according to isArray from
> an arguments object. At least the Array.prototype.concat method
> discriminates on
> Error: Failed to load processor Class
> No macro or processor named 'Class' found
> == "Array". We should provide the necessary minimal tools, at the
> least. Function.prototype.apply would want an isArrayLike predicate,
> but that should be named differently from isArray.
> A "View Selection Source" on the relevant part of the web page:
> method discriminates on </p><div class="system-
> message"><strong>Error: Failed to load processor <code>Class</code></
> strong><pre>No macro or processor named 'Class' found</pre></div><p>
> == "Array".
> Es-discuss mailing list
> Es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss