Brendan Eich wrote:
On Feb 27, 2008, at 3:59 PM, Waldemar Horwat wrote:
I'd like write access to the spreadsheet so we can fill in the Google
column:
http://spreadsheets.google.com/pub?key=pFIHldY_CkszsFxMkQOReAQgid=2
Also, some features have been omitted from the spreadsheet
The optional /hashcode/ argument is a function that takes a key and
returns a numeric code for it. This code may be used to find
associations more quickly in the map. Two calls to the /hashcode/
function on the same key value must return the same numeric code, and
the /hashcode/ function
Steven Mascaro wrote:
One last issue. I was going to leave it till later, but I realised it
may affect ES4.
The nicest syntax for named arguments would be to use ':', just like
with object literals. e.g.:
/// Define
function foo(arg1 = 0, arg2 = 1) { ... }
/// Call
foo(arg2: 10,
new Vector.T ( length=..., fixed=... )
It would be helpful for readability to have the types here.
The |Vector| constructor is implementation-defined.
This is misleading. Usually when a standard states that something is
implementation-defined, it means that its semantics are not specified
intrinsic function propertyIsEnumerable(name: EnumerableId, flag:
(boolean|undefined) = undefined): boolean
I too find the second parameter here abhorrent. Please find another way to
solve it (Brendan's namespace idea maybe) or remove this feature altogether.
How does property lookup deal
The character sequence BACKSLASH lineterminator (where lineterminator
will be one of the characters LF, LS, or PS) is removed from string literals
delimited by either single or triple SINGLEQUOTE or DOUBLEQUOTE characters.
(Triple-quoting is defined in [5].)
This states that:
abc\\
tde
Jeff Dyer wrote:
- Phone calls as needed
Is there one tomorrow? There's a blank agenda page for it.
Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Lars Hansen wrote:
The character sequence BACKSLASH lineterminator (where
lineterminator will be one of the characters LF, LS, or PS) is
removed from string literals delimited by either single or triple
SINGLEQUOTE or DOUBLEQUOTE characters. (Triple-quoting is
defined in
[5].)
This
Lars Hansen wrote:
The feature was approved by the WG and solves a practical problem.
If another way to solve this practical problem is proposed (in a
more structured form than in the ongoing discussion) and finds favor
with the WG, then fine -- of course we can replace it. Until then,
this
Jeff Dyer wrote:
Waldemar, can you suggest a fix?
The correct fix is to add the relevant productions to the lexer grammar. It's
fairly straightforward in the string literal grammar. It's painful in the
regexp grammar.
Waldemar
___
Es4-discuss
Lars Hansen wrote:
In my opinion the following is roughly right:
obj.eval(x)
if eval is the original global eval function then
if obj is an ES global object (window, frame) then
invoke eval as follows:
the scope chain holds that window (global) object only
the
Yuh-Ruey Chen wrote:
Brendan Eich wrote:
If we end up making all namespaced properties non-enumerable, then we
may want a property iterator that returns the names of all properties
in a given object. Even if this is not in the standard, it's likely
to be an extension. Or it could be
I agree with Lars on this issue for exactly the same reasons as what he stated.
Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Here are my comments on this section:
static public function apply(fn /*: function*/, thisArg: Object=null,
argArray: Object=null)
static public function bind(method /*: function*/, thisObj: Object=null,
...args)
static public function call(fn /*: function*/, thisObj: Object=null,
The current definition in 1.2.2 of what Map(o) does is a harmful dead end. The
current behavior is:
- If o is already a Map then leave it alone.
- Otherwise enumerate the visible properties of o and construct a Map out of
those.
This is harmful because it's guaranteed to cause current and
Mark S. Miller wrote:
The one use-case I can see for names and namespaces that isn't
addressed adequately by existing patterns is expanding the
property-name-space, to avoid accidental collisions on extensions to
common abstractions. I note that Smalltalk has long faced this issue,
and I know
Doing this would require multiple inheritance if you tried to apply it to a
two-level class hierarchy.
class A.X;
class B.X extends A.X;
Now consider where the unqualified type B would belong in the hierarchy.
Waldemar
Peter Hall wrote:
Note that this is not to say that the type Cls is
There is no solid technical reason for requiring parentheses here. They're
here because of people's preferences. I don't find them particularly useful
here.
Waldemar
Peter Hall wrote:
Now that union type uses | instead of , for the delimiter, could
the parentheses be made optional? It
Lars Hansen wrote:
Please define the terms forgeable and unforgeable in the
synopsis before using them later.
The terms are (will be) defined in the language part of the spec,
and there is already an entry in the NOTES section that defines
what they mean for the moment, since the language
Mark Miller wrote:
- Disable FunctionObject.arguments (not actually in ES3 but
woefully used in practice)
This is an interesting one, since disallowing it would mean that
the ES3.1 and ES4 specs would have to re-allow it so that they could
explicitly disallow it :)
Yes. It's also
My views on this are:
- There should be only *one* syntax for specifying namespaces in definitions.
It shouldn't be
ns::foo = xyz
in one place (object initializers) and
ns var foo = xyz
someplace else (variable definitions).
- The historical reason I chose the syntax
ns var foo = xyz
for
Michael O'Brien wrote:
As a follow up, the following somewhat surprised me.
{
let b = 1
{
function fun() {
print(CALL: + b)
}
}
}
fun()
gives:
**ERROR** EvalError: uncaught exception: ReferenceError: unresolved
lexical reference
My comments:
The grammar doesn't work:
{meta::prototype:17}
can be parsed as either a FieldName or as the meta::prototype production. To
make parsing unambiguous you can't allow meta to be included in AnyIdentifier
(or implement some other similar fix).
Class type discussion:
Do the
There is also another ambiguity in the grammar:
var {x:y, p:q} = expr;
is both an assignment expression statement and a destructuring variable binding
statement.
Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
My comments:
The grammar is ambiguous.
var [x, y] = expr;
is both an assignment expression statement and a destructuring variable binding
statement.
How does the length property work for structural type literals? Is it always
a fixture?
If the array initializer is prefixed by |const|
There is an old downside to the attribute syntax: You can't put line breaks
between the attributes and the definition, even though it's tempting to do so
on long lines. Otherwise you silently change the meaning of existing ES3 code
like:
foo
var bar = 3
Waldemar
Jeff Dyer wrote:
Here
My comments on this chapter:
The operator form of eval is used before it's described, which confused me
while reading this document.
It bothers me that the eval operator form and the eval function form produce
different valid results for the same input. If we provide both and both are
My comments on this chapter:
I understand and agree with the simple form of iteration though an object using
the empty set of namespaces.
On the other hand, I don't see why extending this beyond that functionality is
useful. It makes things larger and more complicated and, given that
Mark S. Miller wrote:
2008/4/6 Jeff Dyer [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Every unforgeable namespace is considered non-equal to every other
namespace.
*Implementation*
fun compareNamespaces (n1: NAMESPACE, n2: NAMESPACE) : bool =
case (n1, n2) of
I agree with everything except:
* reserved namespaces may not be aliased (ie they are illegal
on the right hand side of = in namespace ns1 = ns2)
If we want to make reserved namespaces into keywords, that might be ok.
However, at the current time they're not keywords, and one could write:
Brendan Eich wrote:
On Apr 25, 2008, at 2:08 PM, Brendan Eich wrote:
for (prop in obj) {
... obj[prop] ...
}
to look like
for each (value in obj) {
... value ...
}
where obj might be an Array. The symmetry between for-each-in and for-
in that E4X half-supports (viz,
Are we having a meeting in Vancouver? What day and time and what's the agenda?
Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Lars Hansen wrote:
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 28. april 2008 18:39
To: Lars Hansen
Cc: es4-discuss
Subject: Re: ES4 note: Reserved namespaces
I agree with everything except:
* reserved namespaces may not be aliased (ie
Brendan Eich wrote:
On Apr 28, 2008, at 6:50 PM, Lars Hansen wrote:
To my knowledge we are not having a meeting in Vancouver. The next
scheduled meeting for ES4 work is the TC meeting in San Francisco
at the end of May.
That's right -- the tentative plan for a meeting in Vancouver fell
This wouldn't work. Without syntactically distinguishing a / that is a
division from a / that starts a regexp, there is no way to find the end of the
block. To make this distinction you need to be able to parse the contents of
the block without errors.
To complicate matters further, various
that it never executes due to the if (false). You can make guesses
based on indentation and such but guesses don't belong in a standard.
Waldemar
Waldemar Horwat wrote:
This wouldn't work. Without syntactically distinguishing a / that is a
division from a / that starts a regexp, there is no way
Mike Shaver wrote:
On Thu, Jul 10, 2008 at 1:48 AM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
FWIW, this sort of thing is a reason that I'm pretty concerned about
ES3.1 getting into an advanced specification state without the benefit
of any in-browser implementation.
You need to have an
Brendan,
You're beating a dead horse here. If this call to eval is allowed, the only
reasonable answer is 21. All that means is that you must be able to recreate
the bindings if the function uses eval. Unless you're proposing to take
block-scoped declarations out of ES4, what's the harm
David Jones wrote:
After I wrote a blog article on this subject someone suggested I
raise the issue here.
Currently, ECMA 262 3rd edition section 9.8.1, the ToString operator
permits implementations to vary in how they convert certain numbers
to strings. For example the number 5e-324
Igor Bukanov wrote:
It seems the current IE7/IE8 behavior is to allow Cf only in srtring
and regexp literals and to allow BOM only in string/regexps or at the
beginning of the source,
Precisely what does in string and regexp literals mean? The exact
interpretation of this phrase is the core
Allen Wirfs-Brock wrote:
In summary, not providing reflective access to an object's prototype doesn't
really provide any real security, it just makes some useful tasks less
convenient. Reverting to barnyard analogies: the barn door is already wide
open and we're debating an inch wide
Ingvar von Schoultz wrote:
Some people yearn hotly for __proto__, preferrably writable if
at all possible, while others point to problems with security
and software privacy.
I get the impression that this could be solved by adding a fourth
flag among the property flags Enumerable, Writable
We've been down this road before, and the arguments you present have been
hashed out over years. This approach doesn't work. Read the archives of the
ES4 group.
The problem is that you then get a plethora of ways to define things:
var
const
function
type
namespace
let
let const
let function
43 matches
Mail list logo
