PROTECTED] wrote:
Peter Hall wrote:
On 8/14/07, Eylon Stroh [EMAIL PROTECTED] wrote:
From the proposal:
The return type T2 is ok, even if the function returns a T1 instead...
covariant occurrences of Self (eg in the result type) are replaced by
T2
I was also wondering about
Minor nitpick, but that should be === not ==.
I really like the idea, but probably it should be done in a way that
could be generalised beyond just the RegExp case. And that doesn't
seem like something that can be done in the es4 time-frame.
But already you can do something like this:
var str;
After searching through the wiki and ecmascript.org site, I still
can't see any formal or informal explanation of how like and is
like work, except in passing, and not with precision. Does this
information exist somewhere?
Peter
___
Es4-discuss mailing
Thanks. A bit more formal than was expecting, but I think it contains
what I'm looking for.
Peter
On Nov 14, 2007 3:36 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Nov 14, 2007, at 11:40 AM, Peter Hall wrote:
After searching through the wiki and ecmascript.org site, I still
can't see any
The argument (which I do not think is decisive) is that PTC breaks
debugability.
I am a bit out of my depth in this discussion, but explicit syntax
feels wrong to me. However, if it's going to be implicit, it has to be
completely invisible (aside from the benefits) - developers are going
to
Tail calls do not have to be self recursive. Only a stack could
maintain the necessary state...
Ah yes, I see that now. Duh.
You can easily circumvent an expression being in tail position. For
example, if EXP is in tail position and you want it not to be, just wrap
it as:
let (r =
Packages, combined with 'internal', are a specialized subset of
namespaces, with usage restrictions and a convenient syntax to cater
for a common use case. Namespaces are more general: any declaration
(local variables or any function or variable defined in a package,
class, structural type or
ES4 needs to treat getter/setters identically to normal vars.
Otherwise it kind of defeats the point of having them.
I would expect:
var fun = width;
to *invoke* the getter. In that particular case, I'd expect a compile
error because width can't be accessed from static scope, exactly as
From the discussions that I can recall, I thought it was to permit
more complex type combinations, adding intersection types using .
(which is why I like the change).
Peter
On Feb 13, 2008 11:48 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Feb 13, 2008, at 3:46 PM, Peter Hall wrote
- Union types are spelled (x|y|z) now, not (x,y,z).
Popularity contest, the pipe character won.
Didn't notice that change! (and I like it :))
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
Was decimal ruled out as its own type?
Peter
On Wed, Feb 27, 2008 at 5:58 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Feb 27, 2008, at 5:33 AM, Lars Hansen wrote:
None of the above speaks to the possibility that decimal might be
a distinct data type in the language, of course, along
:58 AM
To: Peter Hall
Cc: es4-discuss Discuss; TC39; Mike Cowlishaw
Subject: Re: Adobe position paper on the ECMAScript 4 proposal space --
decimal
On Feb 27, 2008, at 10:40 AM, Brendan Eich wrote:
First, nothing's ruled out -- you're asking the wrong guy if you
want Adobe's
, and bind to the normal method otherwise).
Peter
On Thu, Feb 28, 2008 at 2:43 PM, Lars Hansen [EMAIL PROTECTED] wrote:
-Original Message-
From: Dick Sweet
Sent: 27. februar 2008 23:27
To: Lars Hansen; 'Peter Hall'
Cc: 'Brendan Eich'; 'es4-discuss Discuss'; 'TC39'; 'Mike Cowlishaw
Except that it would have a few unexpected behaviours, especially
around the and characters.
Peter
On Wed, Mar 5, 2008 at 11:53 PM, Igor Bukanov [EMAIL PROTECTED] wrote:
On 06/03/2008, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
If I understand the motivation for triple quoted strings,
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... How would you define a
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
rendered useless
If there is no method to make a property enumerable again (which I now
agree is better not to exist) it feels somehow bad to be able to make
a property non-enumerable after its declaration.
Consider:
let a = {b:2, c:3};
for(let s in a){
print(s); // b, c
}
a.__makePropertyNonEnumerable__(b);
Is there enough value in complicating matters by adding the ability to
set dontDelete and readOnly? You can create non-deletable properties
by using a class or record type, and you can create read-only
properties by adding a get function without a corresponding set...
Are there any use cases
I have a few questions/comments about parametrized types. Some I know
has been discussed, but I still unclear on the outcome of those
conversations.
1. If there is a type T.J,K, can T be referenced itself, or must it
be referenced for some specific values of J and K?
That is, can I say:
T1 = T;
Perhaps, something like this:
var n1 = new Name(foo, bar);
var n2 = new Name(foo, bar);
n1.toString = function(){.}
An implementation might have reasonably shared the same instance for
n1 and n2, but a user might be surprised that the new toString()
function is now found on what he
Now that union type uses | instead of , for the delimiter, could
the parentheses be made optional? It seems like parentheses are used
elsewhere only for grouping and function calls/definitions.
UnionType ::= Type ( | UnionType )?
which should be easily distinguishable from a bitwise OR
, 2008 at 10:46 PM, Waldemar Horwat [EMAIL PROTECTED] wrote:
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
Replacing a method effectively changes the type, even if the signature
is the same. If some code creates an instance of a class using new
it should be able to rely on it being that type, and make assumptions
about how that object will behave. (This is not a matter of breaking
polymorphism because
Some time last year I started a brief discussion about passing
arguments to super() in a constructor, when it is automatically
inserted. (https://mail.mozilla.org/pipermail/es4-discuss/2007-June/000846.html)
The most common use-case from Flex/AS3 is probably for custom events,
where you'd write
Since both modes are to be specified by upcoming standards documents,
can we adopt some term other than standard for the mode we'd like to
discourage? I propose loose.
I agree. But I think lenient sounds better.
Peter
___
Es4-discuss mailing
Not sure, but there might be something in the super syntax (eg, super.x
= 10) that
would do this. Hasn't been spec'd yet. Not sure what AS3 does.
In AS3 it's like this:
override function set bar (value) {
super.bar = value;
}
Peter
___
Here's my take at an example of brittleness:
var bar = 42;
class foo {
function zot () { return bar; }
}
...
class subfoo extends foo {
var bar = 'oops!';
}
(new foo).zot() = 42
(new myfoo).zot() = ?
In AS3, the reference to bar in the zot function would be bound to
this.bar
27 matches
Mail list logo
