I agree. I don't see why there should be multiple syntaxes that are as
concise as each other and both have about equal precedent (AS3 vs. E4X).
If in some futuer spec, properties can inhabit multiple namespaces, then
we can consider the |ns1 ns2 ... var foo| syntax again.
-Yuh-Ruey
Waldemar
is
ES3 and another part ES4, or how a program is pure ES4?
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Peter Hall wrote:
The latter. It is weird, I agree. But the enumerator can easily be
customized, so I want the default enumerator be as non-magical as
possible - and therefore, as simple as possible. In fact, I'm a bit
bothered that propertyIsEnumerable is a method of Object yet can be
Peter Hall wrote:
Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
Which gets me back to the cognitive load issue. Even with a name like
'hidden', they may think they may have to do some funky syntax like
|obj.hidden::other_ns::prop| do hide a prop in another namespace.
This was confusing me
Brendan Eich wrote:
On Mar 9, 2008, at 3:01 PM, Yuh-Ruey Chen wrote:
Brendan Eich wrote:
ES3 code can't detect namespaces, so arguably shouldn't care if we
were to implement DontEnum using an open namespace. But this could be
a problem for mixed ES3 and ES4 scenarios where the ES4 code
Brendan Eich wrote:
On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
But doesn't DontEnum still have to be there for ES3 objects? How else
would you prevent the enumeration of ES3 builtin methods, e.g.
Object.prototype.toString()? Or is there some more open namespace
magic
that I'm
for enumerability.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
dontenum is fine.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
More clarifications and updates to my proposal:
Yuh-Ruey Chen wrote:
The only real non-syntactic issue between type exprs and value exprs is
that in type exprs, the identifiers must be fixed type properties.
Everything else, such structural types and function types (ignoring the
identifiers
in range(10))
print(x);
No mention of StopIteration - or even next() - anywhere in that code yet
|range(10)| is clearly an iterator.
In case you were wondering, ES4's iteration protocol is heavily inspired
from Python, and I think Python has handled this iteration business very
well.
-Yuh-Ruey
Yuh-Ruey Chen wrote:
If the main problem is that value exprs and type exprs are incompatible,
then why not make them compatible? Make it so that the only difference
between the two is that type-expr-like value exprs evaluate to
meta-objects and actual type exprs require fixed type properties
By fixed, do you mean an RI bug or a spec issue? If it's just an RI
bug, can you tell me what those exprs are supposed to evaluate to?
-Yuh-Ruey Chen
Lars T Hansen wrote:
At present, generic functions do not discriminate on structural types.
This probably needs to be fixed, but I've
, another goal becomes more
compromised. Maybe we can place priorities on these goals? If we can
abandon one or two of these in favor of the other goals, this job would
be much simpler. Need to think on this some more...
-Yuh-Ruey Chen
___
Es4-discuss mailing
Garrett Smith wrote:
JavaScript does not provide basic functionality for unique collections.
It's trivial to implement an efficient Set class even in ES3 (with
certain restrictions on the type of the key) - just use objects which
are pretty much specialized hash tables (maps from string to
Brendan Eich wrote:
On Nov 11, 2007, at 3:09 PM, Yuh-Ruey Chen wrote:
Sorry, I'm still not getting it. The upgraded |instanceof| will behave
exactly the same for the inputs non-upgraded |instanceof| works on.
There are new guarantees, but they in no way affect the original ones.
They're
to accusations with
more accusations is plain sophomoric in my book. Please, I have enough
of my political bullshit from the news - I don't expect that here.
Thanks, Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org
. But we already have such huge features like
classes, generators, namespaces, type system, and now generic functions.
Perhaps we should start deferring more features to ES5?
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https
said, I don't have a clear view of the spec as a whole, so I'll wait
until there are good prose sections describing the usage of features
before coming to a conclusion.
-Yuh-Ruey Chen
Garrett Smith wrote:
On 10/21/07, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
Hey all,
I've been watching ES4
18 matches
Mail list logo
