FWIW, I definitely like this proposal more than any convoluted
var-scoping block proposal.
I just don't see the value of adding var-scoping blocks for the added
parser complexity, and problematic return/break/continue.
Even if the return/break/continue problem is solved, it shouldn't just
be f
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 Ho
roperty__(prop, value)
obj.__setProperty__(prop, value, Object.DONT_ENUM)
obj.__setProperty__(prop, value, Object.READ_ONLY, Object.DONT_DELETE)
obj.__getPropertyAttribute__(prop, Object.READ_ONLY) // returns true or
false
BTW, names subject to change (could be just DONT_ENUM, or
Object
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
S3+4 mixture - how would you tell that one part 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:
> 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
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
> >>
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
amespace values, but the values depend on the context of the use." As
the wiki doesn't talk about this, and the online spec is
inaccessible/outdated, can you elaborate on this? I wonder if 'private'
could be used somehow for enumerability.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
totype.iterator::isPropertyEnumerable(prop) which
> > delegates to
> > Object.prototype.isPropertyEnumerable(prop).
>
> Clever relocation of "is" in the predicate names ;-). We're probably
> stuck with propertyIsEnumerable.
>
Honestly, that wasn
ty is planned for a future ES edition,
then I think dontenum is fine.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
*
static meta function invoke(a, b=undefined): Name
new Name(a, b);
If a is already a Name, shouldn't Name(a) simply return a? Not sure what
the policy on this is, but if you've changed Map to work similarly, then
I don't see why not here as well.
Brendan Eich wrote:
> On Dec 21, 2007, at 7:33 AM, StevenLevithan wrote:
>
> > Yes, its easy to pull off oneself, so I don't care much other way.
> > Still, it
> > seems pretty weird to me to be able to do ``regex(str)`` but not
> > ``regex.call(context, str)``. This is accentuated when typeof re
Sounds like a good idea to me. On the other hand, this can already
easily be done in ES3.
Steven L. wrote:
> ES4 proposals include making regexes callable as a function on a
> single string argument, which serves as a shorthand for calling the
> regex's exec method. To further extend this idea, wh
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 (ign
print(k);
FYI, the original ES3 for-in is actual a special case of the ES4 for-in.
When you do |for (let p in obj)|, it's actually iterating over obj's
intrinsic iterator (obj.iterator::get() according to the wiki), which
enumerates obj's properties, just like what it does in E
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 requir
ible to create a class to emulate such
constraints, maybe we ought to do something about it...
-Yuh-Ruey Chen
liorean wrote:
> Hello!
>
> Since we now have a namespace for uint specific math operations, and
> discussion in another thread about using pragmas for throwing if
> assigning
oo(a: {p: int})
// |instanceof| shares same syntax with |is| now:
x instanceof int
x instanceof like int
x instanceof (like T1 | type {p: V2})
// but still works with constructors (even if meaningless)
x instanceof function(){}
// valid type annotations:
var x: T1
var x: type [T1]
var x: like type {
siness very
well.
-Yuh-Ruey Chen
Erik Arvidsson wrote:
> One benefit of StopIteration is that code inside map/some/every etc
> can just throw a StopIteration to stop the iteration. The same thing
> is harder to keep clean with a hasNext/next pattern.
>
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 b
annotations coherent.
3) Keep |is| and |instanceof| (somewhat) coherent.
4) Keep all the type operators coherent (to a certain extent).
5) Try not to introduce too many exceptions to the rule a.k.a. gotchas.
Whatever we do to advance one goal, 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 list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
t the
> nominal types. Unbounded type parameters are not classically "Java-
> esque", and Java generics go beyond what we are doing in some ways
> (variance annotations) while still being much less (erased, static
> only) in others. ES4 is a dynamic language. Java-esque doesn't begin
> to do it justice.
>
Oh come on :) I was referring to the syntax of the class system, which
is undoubtedly Java-esque. Lot of Java haters in the functional (no
1st-class functions!) and scripting (too verbose!) programming crowd.
Pretty much everyone's first impression of the class system in ES4 is
that Java is being merged into the language. Kinda like how everyone
thinks that Java inherited its type system from C++ instead of Modula-3.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
ow that S1 <: Object, but is S2 <: S1? I've looked at
http://wiki.ecmascript.org/doku.php?id=clarification:type_system and
it's not clear to me. Is it still true that C <: S1?
-Yuh-Ruey Chen
___
Es4-discuss mailing list
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
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 t
AS3 already has an |is| operator that works
similarly, so that may be another barrier to this solution. |instanceof|
composed with |like| also sounds awkward, e.g. |instanceof like type {a:
int}|, unless it's the other way around, e.g. |instanceof type like {a:
int}|.
3) Let |is| work on value exprs, and upgrade |instanceof| to work on
everything |is| works on. Again, not sure what you mean be guarantees.
This solution doesn't require the removal of |is| and so is more
compatible with AS3. On the other hand, the fewer keywords, the better.
4) As you say (I think), |is| may be too overloaded. That it works both
classes/interfaces and structural types even though the two are very
distinct tests is a cause for concern. Yet it is convenient to group
them into one operator.
In addition to all that, if |is| works on value exprs, there's still the
confusion I've previously pointed out:
// |b| is a class, |a| is instance of |b|
a is type b
a is b
Maybe we can just explain to the user that |type| is only required for
structural types to avoid syntactical ambiguity (in the same vein as
block {} vs. object literal {})?
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Brendan Eich wrote:
> I'm going to summon Graydon and stand back now.
>
> /be
>
Right, I'll wait to reply in full until then. I just want to point out
that the spec namespace isn't public.
http://wiki.ecmascript.org/doku.php?id=spec:spec gives me a "permission
denied" page.
Brendan Eich wrote:
> On Nov 9, 2007, at 11:24 PM, Yuh-Ruey Chen wrote:
> > Ah, so expressions can be annotated with types?
>
> Array and object initialisers can be annotated with array and object
> ("record") structural types to make the expressed object have fixed
Brendan Eich wrote:
> On Nov 9, 2007, at 5:29 PM, Yuh-Ruey Chen wrote:
>
> > The confusion I'm getting is that there seems to be many ways to check
> > or differentiate between types. For example, consider the following
> > ES3
> > function:
> >
Graydon Hoare wrote:
> Yuh-Ruey Chen wrote:
> > I've been experimenting with the ES4 RI lately. I've discovered that the
> > following doesn't work:
> >
> > x = int;
> > 10 is x;// error
> > 10 to x; // error
> > 10 cast x; //
operators are
implemented in the RI yet, so I couldn't really test out structural types.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Yuh-Ruey Chen wrote:
> By "generic functions ought to be available on instances", do you mean
> non-global generic methods? TBH, I consider generic functions a bit of
> an odd fuck in ES4, because of its many restrictions compared to normal
> functions (see the "non-
on instances", do you mean
non-global generic methods? TBH, I consider generic functions a bit of
an odd fuck in ES4, because of its many restrictions compared to normal
functions (see the "non-features, future directions, etc." section on
the generic functions proposal).
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
se a union type with a tuple type.
-Yuh-Ruey Chen
Jason Orendorff wrote:
> On Oct 26, 2007 6:35 PM, James Clark <[EMAIL PROTECTED]> wrote:
> > (int, string) doesn't seem to me to be a syntax that the average JS
> > programmer will guess means union. I would have thou
tructive at all. Responding 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@m
se for program units and packages. But like I
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 <[EMA
fine by me. 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
38 matches
Mail list logo
