OK. I'll make a brief annotation on the proposal page about
left-to-right interpretation so that we can move on and say that we've
accepted the proposal; when the grammar is later written up there should
be no room for confusion about what the intent of this proposal was.
--lars
-Original
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 added in the future.
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
the frequency of use). Thus on Object.prototype and as an
intrinsic propety on Object instances:
function __createProperty__(name:EnumerableId,
dontEnum:boolean=false,
dontDelete:boolean=false,
Why doesn't Function have something like apply that does the same as
in a new expression, i.e. allocate-init-and-apply? To put it another
way: given arguments in an array, I want to write:
F.thisThing(args) and have it mean the same as new F(args[0], args[1],
... args[n-1])
Or is what happens
Hi Dustin,
Well it does, apparently it was called the splat operator, which (to
me) sounds a better than spread. I think it works like:-
var args = [12, true];
new C(...args);
function C( count, isSemiAnnual) {
}
- Maybe one of guys writing the specs can comment on that.
It can be hacked in
Neat! Thanks for the link.
Dominic
On Thu, Mar 13, 2008 at 10:58 AM, Jon Zeppieri [EMAIL PROTECTED] wrote:
On Thu, Mar 13, 2008 at 1:48 PM, Dominic Cooney
[EMAIL PROTECTED] wrote:
Why doesn't Function have something like apply that does the same as
in a new expression, i.e.
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
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
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Hall
Sent: 13. mars 2008 12:38
To: Lars Hansen
Cc: Kris Zyp; es4-discuss@mozilla.org
Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
Is there enough value in complicating matters
set dontDelete and readOnly? You can create non-deletable properties
by using a class or record type
They can't be added after an object is created.
and you can create read-only
properties by adding a get function without a corresponding set...
Unless behavior is different than ES3, setters
On 13/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Since our method is creating a new property and not setting
one, I suggest __createProperty__ as the most appropriate
name, so I'm going to use that below.
Sounds perfectly reasonable to me.
I still think it may be right that properties
On Mar 13, 2008, at 11:47 AM, Lars Hansen wrote:
function __createProperty__(name:EnumerableId,
dontEnum:boolean=false,
dontDelete:boolean=false,
readOnly:boolean=false): void
I like where this is going.
-Original Message-
From: Neil Mix [mailto:[EMAIL PROTECTED]
Sent: 13. mars 2008 14:47
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
On Mar 13, 2008, at 11:47 AM, Lars Hansen wrote:
function
On Mar 13, 2008, at 2:07 PM, Lars Hansen wrote:
-Original Message-
From: Neil Mix [mailto:[EMAIL PROTECTED]
function __createProperty__(name:EnumerableId,
value:*,
enumerable:boolean=true,
FWIW, AS3, which doesn't have iterators, enumerates only the expando
properties of an object. This was in part because we didn't have (qualified)
name objects that could be enumerated, and in part because of it being
complicated to determine the set of names that could be safely exposed (e.g.
all
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,
On Mar 13, 2008, at 3:39 PM, Lars Hansen wrote:
Firefox currently has that new Namespace (for E4X) produces
a new object that is == to another namespace produced with the
same string but not ===. From looking at the code, ActionScript3
does the same thing. Ditto for names (QName in E4X, not
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 11. mars 2008 19:17
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Name
public function Name(a, b=undefined)
static meta function invoke(a, b=undefined): Name
It would be help the
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 12. mars 2008 18:54
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Namespace
Here's my review of this section:
Is null a valid value of the class Namespace? The
description states
From: Neil Mix [mailto:[EMAIL PROTECTED]
function __createProperty__(name:EnumerableId,
value:*,
enumerable:boolean=true,
removable:boolean=true,
writable:boolean=true): void
Speaking for myself, I should say from the outset that I am
not in favor of taking this much further than it has been
taken. The base language is ES3; we're trying to fix a
small problem in that language in the cheapest possible way.
I would rather backtrack to a solution that only fixes the
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 13. mars 2008 17:35
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Namespace
Lars Hansen wrote:
The natural behavior on etc would be as in ES3, ie, if valueOf on
namespace returns
I suppose we could simply state that two Namespaces yield the
same string value iff they are ===, and that two invocations
of toString()
... on the same Namespace object ...
always yields the same string. Doesn't seem
particularly onerous, it would probably be the case in most
On Mar 13, 2008, at 4:43 PM, Lars Hansen wrote:
I suppose we could simply state that two Namespaces yield the same
string value iff they are ===, and that two invocations of toString()
always yields the same string. Doesn't seem particularly onerous,
it would probably be the case in most
On Mar 13, 2008, at 4:05 PM, Lars Hansen wrote:
Why does valueOf do a toString on the Name?
Entirely because the original spec (on the wiki) required it. I
suspect
this is the wrong design (and I think even Brendan, who wrote it up,
questioned it, because it's left as an open issue on
the fact; getters and setters defined by an object initializer
or in a class are fixtures and hence not deletable.
Really, that doesn't create a compatibility problem? I realize getters and
setters aren't in ES3, but this seems like ES4 would be making a significant
departure in behavior from
28 matches
Mail list logo
