That sore thumb propertyIsEnumerable.
propertyIsEnumerable, as a setter, sets the DontEnum flag for the
object's own property. A value of 'false' makes the prop not show up
in - for in.
propertyIsEnumerable, as a getter, gets the value of the negation of
the DontEnum flag, and does not check the
[Coming late to the party]
On 2008-03-13, at 12:47 EDT, Lars Hansen wrote:
function __createProperty__(name:EnumerableId,
dontEnum:boolean=false,
dontDelete:boolean=false,
readOnly:boolean=false): void
If
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: 7. april 2008 16:20
To: es4-discuss@mozilla.org
Subject: RE: ES4 draft: Object initializers
Here is the second draft, which incorporates most things
discussed so far. Changelog
-Original Message-
From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: 8. april 2008 15:38
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object initializers
On Tue, Apr 8, 2008 at 12:20 PM, Lars Hansen
[EMAIL PROTECTED] wrote:
One facility
var (outside of eval, an ES1 flaw) means DontDelete.
/be
On Apr 7, 2008, at 1:50 PM, Mark S. Miller wrote:
On Mon, Apr 7, 2008 at 10:21 AM, Lars Hansen [EMAIL PROTECTED]
wrote:
IMO it ought to be possible to use 'var' in those same ways but we
didn't discuss that much (if at all).
I
On Mon, Apr 7, 2008 at 2:47 PM, Brendan Eich [EMAIL PROTECTED] wrote:
var (outside of eval, an ES1 flaw) means DontDelete.
Excellent!
--
Cheers,
--MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
I can ask `o[f] !== undefined` to determine if a defined property
named `f` exists in `o`, whether `f` is a fixture or not, correct? If
I only have `o`, is there a way for me to detect whether `f` is
implemented as a getter in `o`, or is that completely invisible to me?
On 2008-03-20, at
: 21. mars 2008 05:15
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object initializers
I can ask `o[f] !== undefined` to determine if a defined
property named `f` exists in `o`, whether `f` is a fixture or
not, correct? If I only have `o`, is there a way for me
]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: 20. mars 2008 16:43
To: es4-discuss@mozilla.org
Subject: ES4 draft: Object initializers
I've attempted to sum up everything we have decided about
object initializers (aka object literals). A short draft
spec is included.
Comments welcome
I've attempted to sum up everything we have decided about object
initializers (aka object literals). A short draft spec is included.
Comments welcome from everyone, especially from ES4 WG members who might
remember about things I've forgotten, or correct misunderstandings.
--lars
Title: Object
On 21/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
I've attempted to sum up everything we have decided about object
initializers (aka object literals). A short draft spec is included.
Comments welcome from everyone, especially from ES4 WG members who might
remember about things I've
On 3/20/08, Lars Hansen [EMAIL PROTECTED] wrote:
Thanks for pointing some of these out, Brendan did the same. This is
already legal to define catch-alls:
{ var meta::get: function () { ... } }
Is there a more recent version of the grammar than the docs at
Draft 3 of the spec for the Object class. Changelog near the beginning.
(Notably this version includes draft code for __createProperty__.)
--lars
Title: The class "Object"
The class Object
NAME: "The class 'Object'"
FILE:
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,
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 __createProperty__
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
From: Neil Mix [mailto:[EMAIL PROTECTED]
function __createProperty__(name:EnumerableId,
value:*,
enumerable:boolean=true,
removable:boolean=true,
writable:boolean=true): void
that of __createProperty__.)
--lars
-Original Message-
From: Mark S. Miller [mailto:[EMAIL PROTECTED]
Sent: 13. mars 2008 17:22
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
From: Neil Mix [mailto:[EMAIL PROTECTED]
function
On Mar 10, 2008, at 7:01 PM, Lars Hansen wrote:
We are the WG. Are you saying that substantive discussions
of your proposals are not welcome? Not sure what the point
of participating is if that's the case.
Sorry, I didn't realize that I find it abhorrent qualified as
substantive
On Mar 10, 2008, at 9:54 PM, Mark Miller wrote:
ES3 has several abstraction mechanisms:
* lambda abstraction, which it gets approximately as right as Scheme!
* objects as a generalization of records, which has some pros and cons
* prototype-based sharing of common behavior, which is used
ES3 has several abstraction mechanisms:
* lambda abstraction, which it gets approximately as right as Scheme!
* objects as a generalization of records, which has some pros and
cons
* prototype-based sharing of common behavior, which is used almost
exclusively by JavaScript programmers to
On Mar 10, 2008, at 11:14 PM, Maciej Stachowiak wrote:
The optional second argument to make propertyIsEnumerable a setter has
some practical problems:
1) It violates the very strong norm that getter and setter functions
are separate and have their own different arguments. It will make the
On Mon, Mar 10, 2008 at 11:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
[...] I'd like to propose the following three alternatives to the
current proposal:
1) Remove the feature entirely from ES4 (as part of the judicious
feature cuts process) until a more appropriate syntax is found
On Mar 10, 2008, at 11:35 PM, Mark S. Miller wrote:
On Mon, Mar 10, 2008 at 11:14 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
[...] I'd like to propose the following three alternatives to the
current proposal:
1) Remove the feature entirely from ES4 (as part of the judicious
feature
On 11/03/2008, Maciej Stachowiak [EMAIL PROTECTED] wrote:
This is not unreasonable, but if adding to Object.prototype is truly
terrifying then I think the approach Mark Miller linked to, of static
methods on the Object constructor, is cleaner:
/snip/
It might even be better to make this
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
Hi Mark, I agree with a number of your objections. I hope you don't mind
if I try to distinguish between some of the points I agree with and
disagree with.
The current fad in language design is expressive static type systems.
As a result, several recent type systems have grown eat their
1) Remove the feature entirely from ES4 (as part of the judicious
feature cuts process) until a more appropriate syntax is found
Setting dontEnum is immensely valuable as a framework developer. I realize
that is not a very technical argument, but controlling dontEnum is of more
value than
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...
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
On Mar 11, 2008, at 1:14 AM, Maciej Stachowiak wrote:
The optional second argument to make propertyIsEnumerable a setter has
some practical problems:
1) It violates the very strong norm that getter and setter functions
are separate and have their own different arguments. It will make the
Here is a modest proposal based on Mark's and Maciej's messages:
Goal: A detectable method requiring no new syntax to set the DontEnum
attribute on an existing property.
Goal: Avoid breaking any existing ES3 code that might depend on a
plainly named method not being predefined.
Anti-goal:
The use of a __-bracketed name satisfies the second goal, but it
would be a problem for Caja or similar. This is an issue where I
would appreciate Mark's feedback.
I can't speak for Mark, but it seems like it might actually be beneficial
that unsecured code (regular ES4) would have the
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);
On Tue, Mar 11, 2008 at 2:32 PM, Peter Hall [EMAIL PROTECTED] wrote:
Perhaps you can't achieve this without new syntax, but the declarative
approach seems cleanest and not prone to this sort of anomaly. If new
syntax could be considered, an |enumerable| attribute, complemented by
a
[+google-caja-discuss]
On Tue, Mar 11, 2008 at 12:53 PM, Kris Zyp [EMAIL PROTECTED] wrote:
The use of a __-bracketed name satisfies the second goal, but it
would be a problem for Caja or similar. This is an issue where I
would appreciate Mark's feedback.
I can't speak for Mark, but it
It seems wrong that the code should run once one way, and then another
way, but there be no way back. It's not so much that I think there
should be a way back, but I'd rather that than this, which I consider
a weird situation.
Declarative is nice, but as mentioned before, it ignores one of
On Mar 11, 2008, at 5:16 PM, Kris Zyp wrote:
Declarative is nice, but as mentioned before, it ignores one of the
primary
use cases: addition of non-enumerable properties to built-ins (by
libraries,
primarily).
I've read mention of the weirdness of the timing window between the
On Mar 11, 2008, at 3:21 PM, Neil Mix wrote:
On Mar 11, 2008, at 5:16 PM, Kris Zyp wrote:
Declarative is nice, but as mentioned before, it ignores one of the
primary
use cases: addition of non-enumerable properties to built-ins (by
libraries,
primarily).
I've read mention of the
I've read mention of the weirdness of the timing window between the
property definition and it's marking as non-enumerable. That combined
with the above observation makes me wonder if this should really be
obj.__setNonEnumerableProperty__(name, value);
+1
I like it too. Any chance that by
Draft 2 of the spec for the Object class. Changelog near the beginning.
--lars
Title: The class "Object"
The class Object
NAME: "The class 'Object'"
FILE: spec/library/Object.html
CATEGORY: Pre-defined classes (E262-3
On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Draft 2 of the spec for the Object class. Changelog near the beginning.
The draft HTML seems a little broken. There's amp;#x0085 in it early
on, later these appear raw in the source (which displays as an empty
square in Opera and IE8).
And
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
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of liorean
Sent: 10. mars 2008 17:52
To: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object
On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Draft 2 of the spec for the Object class
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 10. mars 2008 18:50
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object
intrinsic function propertyIsEnumerable(name: EnumerableId, flag:
(boolean|undefined) = undefined): boolean
:18
To: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object
On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Draft 2 of the spec for the Object class. Changelog near
the beginning.
The draft HTML seems a little broken. There's amp;#x0085 in
it early on, later these appear raw
On 11/03/2008, Lars Hansen [EMAIL PROTECTED] wrote:
As far as I can see this is not a problem in the file I sent out, nor in
the one I received from the reflector.
What mailer are you using?
Gmail's web interface. And checking, it appears only using the View
link, not the Download link. So
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
-Original Message-
From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
Sent: 10. mars 2008 19:40
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object
Lars Hansen wrote:
The feature was approved by the WG and solves a practical problem.
If another way
On Mon, Mar 10, 2008 at 11:11 PM, Jeff Dyer [EMAIL PROTECTED] wrote:
it would
be helpful to follow up with possible solutions or at least insight into
what makes it abhorrent (your word).
FWIW, I also did not grasp the force of the objection, and would like
to understand better.
No
On Mon, Mar 10, 2008 at 8:11 PM, Jeff Dyer [EMAIL PROTECTED] wrote:
On 3/10/08 5:40 PM, Waldemar Horwat wrote:
I'm dealing with a serious insurrection of folks who believe that the ES4
working group has a bad attitude, based on Brendan's public comments and
responses to issues like this
On Mon, 10 Mar 2008, Waldemar Horwat wrote:
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
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
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of zwetan
Sent: 7. mars 2008 19:28
To: Brendan Eich
Cc: es4-discuss@mozilla.org es4-discuss; Yuh-Ruey Chen; Erik Arvidsson
Subject: Re: ES4 draft: Object
why not have a global utility function, maybe
On 2008-03-07, at 22:43 EST, Brendan Eich wrote:
The goal is to find the minimum amount of mutating meta-programming
sharpness for this make certain properties non-enumerable tool. If
it can be done with a one-time namespace qualification step, that
wins.
A few comments:
I am confused. I
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of P T Withington
Sent: 8. mars 2008 10:10
To: Brendan Eich
Cc: zwetan; es4-discuss@mozilla.org es4-discuss; Yuh-Ruey
Chen; Erik Arvidsson
Subject: Re: ES4 draft: Object
On 2008-03-07, at 22:43 EST
Brendan Eich wrote:
- Users may think this dontenum namespace is magical and yet another
thing to keep in mind, when it really just relies on the namespace
trick
you mentioned. With the introduction of classes and namespaces, the
rules of enumerability are already more complex, so this
Garrett Smith wrote:
obj = {dontenum length: 10} );
vs.
obj = {length: 10};
obj.propertyIsEnumerable(length, false);
Which is more ugly?
Garrett
Of course I prefere the first line but these two cases are different.
I wonder if a builtin method will not cause more problems instead of
Brendan Eich wrote:
To avoid injecting a public name into Object.prototype, we could put
a new setPropertyIsEnumerable (yechh) name in the __ES4__
namespace. Then there's no breaking change. We do this already, of
course, but not for property attribute fiddling.
Since enumerability
On Mar 7, 2008, at 1:14 PM, Yuh-Ruey Chen wrote:
Brendan Eich wrote:
To avoid injecting a public name into Object.prototype, we could put
a new setPropertyIsEnumerable (yechh) name in the __ES4__
namespace. Then there's no breaking change. We do this already, of
course, but not for property
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: 5. mars 2008 19:19
To: Erik Arvidsson
Cc: es4-discuss@mozilla.org es4-discuss
Subject: Re: ES4 draft: Object
To avoid injecting a public name into Object.prototype, we
could
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brendan Eich
Sent: 6. mars 2008 18:04
To: Garrett Smith
Cc: es4-discuss@mozilla.org es4-discuss; Erik Arvidsson
Subject: Re: ES4 draft: Object
Remember that fixtures declared in classes
This is the draft for the Object class. It's very similar to the Object
object in ES3, the only addition (to my knowledge) is the extra
parameter to propertyIsEnumerable. And of course the specification
formalism is new.
Please comment.
--lars
Title: The class "Object"
The class
We (Google) find setting the [[DontEnum]] flag with
propertyIsEnumerable(name, flag) to be quite ugly. I can't find any
references to why the setter was tagged along onto the getter in this
way? Is there a reason why we don't want
setPropertyIsEnumerable(name, flag) instead of overloading the
On Mar 5, 2008, at 5:04 PM, Erik Arvidsson wrote:
We (Google) find setting the [[DontEnum]] flag with
propertyIsEnumerable(name, flag) to be quite ugly. I can't find any
references to why the setter was tagged along onto the getter in this
way? Is there a reason why we don't want
-Original Message-
From: Erik Arvidsson [mailto:[EMAIL PROTECTED]
Sent: 5. mars 2008 17:04
To: Lars Hansen
Cc: es4-discuss@mozilla.org
Subject: Re: ES4 draft: Object
We (Google) find setting the [[DontEnum]] flag with
propertyIsEnumerable(name, flag) to be quite ugly.
Can't
I'm not sure it is such a big issue since the new method would be
[[DontEnum]] but I'm willing to let this rest.
The reason why I don't think it is that a big risk is that a lot of
people still use Array instead of Object for associative arrays and
I don't think adding the array extras introduced
Hixie argued strongly on IRC today for something that does not
overload set with get -- this seems to be the heart of the ugly
objection, although there are other things to dislike about both the
form and function of propertyIsEnumerable (it does not consider
prototypes, as for-in does;
78 matches
Mail list logo
