On 2008-05-15, at 18:48 EDT, Garrett Smith wrote:
> 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
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 p
[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
> -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 PROTEC
On Tue, Apr 8, 2008 at 12:20 PM, Lars Hansen <[EMAIL PROTECTED]> wrote:
> One facility that was introduced in this draft copies the
> type tags of 'const' and 'var' attributed properties into
> the type of the object, for "ease of use". As a consequence,
> this test is true:
I don't understan
> -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 th
Here is the second draft, which incorporates most things discussed
so far. Changelog near the beginning, with an OPEN ISSUES section.
--lars
Title: Object literals
Object initializer syntax
NAME: "Object initializer syntax"
FILE: spec/la
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
https://mail.mozilla.org/listinfo/es4-di
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)
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 don't understand. What would it mean?
--
Cheers,
--MarkM
___
Es4-
quot;foo",true]
}
IMO it ought to be possible to use 'var' in those same ways but we
didn't discuss that much (if at all).
--lars
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> Sent: 21. ma
)
--lars
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> Sent: 21. mars 2008 08:19
> To: es4-discuss@mozilla.org
> Subject: RE: ES4 draft: Object initializers
>
> A bug: repeated fields are also disallowed if th
TECTED]
> [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
lto:[EMAIL PROTECTED] On Behalf Of
> P T Withington
> Sent: 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`
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 19
On 3/20/08 7:00 PM, Brendan Eich wrote:
> On Mar 20, 2008, at 6:04 PM, Jon Zeppieri wrote:
>
>> 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: func
On Mar 20, 2008, at 6:04 PM, Jon Zeppieri wrote:
> 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 o
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
http://wiki.ecmascript.org/d
d
that value back with the syntax.)
--lars
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> Sent: 20. mars 2008 17:13
> To: es4-discuss@mozilla.org
> Subject: Re: ES4 draft: Object initializers
>
> On 21/03/2008, La
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
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 li
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: spec/library/Obj
at 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
>> From: Neil Mix [mailto:[EMAIL PROTECTED]
>>
>> function __createProperty__(name:EnumerableId,
>> value:*,
>> enumerable:boolean=true,
>> removable:boolean=true,
>> writable:boolean
t; Cc: Neil Mix; es4-discuss@mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
>
> On Mar 13, 2008, at 2:07 PM, Lars Hansen wrote:
>
> >> -Original Message-
> >> From: Neil Mix [mailto:[EMAIL PROTECTED]
>
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 t
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,
>>
> -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
> > [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> > ReadOnly would need to be instanciated at the same time, no?
On 13/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> I assume you're referring to my having left the value argument out
> by mistake (second argument).
>
> Or was there someth
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 goi
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> Sent: 13. mars 2008 14:31
> To: es4-discuss@mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
>
> > I still think it may be right th
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 prope
> 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, setter
> -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 e
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 where
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 coul
> -Original Message-
> From: Kris Zyp [mailto:[EMAIL PROTECTED]
> Sent: 13. mars 2008 11:27
> To: Lars Hansen; es4-discuss@mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
>
> > the frequency of use). Thus on Object.prototype and as an
> 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,
> re
-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kris Zyp
> Sent: 11. mars 2008 23:13
> To: Brendan Eich
> Cc: Neil Mix; Peter Hall; es4-discuss@mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: 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
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.
>
>> Object.prototype.__setPropertyWithAttributes__(name, value, dontEnum:
>> boolean, readOnly: boolean, dontDelete: boolean);
>
> Only if you cannot change an existing properties attribute, or delete an
> existing property and create a new one with the same name. Those cases
> would have to fa
On Mar 11, 2008, at 8:32 PM, Kris Zyp wrote:
> I like it too. Any chance that by setting the attribute at the same
> time of
> setting the property value, we could resurrect the possibility of
> setting
> other attributes as well (with a single method):
>
> Object.prototype.__setPropertyWithAt
On Tue, Mar 11, 2008 at 8:32 PM, Kris Zyp <[EMAIL PROTECTED]> wrote:
> >> 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
> >>
>> 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
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
On Mar 11, 2008, at 2:45 PM, Brendan Eich wrote:
> Proposal: Add Object.prototype.__makePropertyNonEnumerable__(name),
> defined as if by:
>
> Object.prototype.__makePropertyNonEnumerable__ = function
> (name) {
> if (this has a direct property identified by name) {
>
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
pr
> 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 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
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");
f
> 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 abil
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: Th
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
On Mar 10, 2008, at 6:43 PM, Yuh-Ruey Chen wrote:
> Ok, that cleared things up a bit. I didn't realize you were making a
> proposal and asking questions based off it :)
This is my fault for being unclear. I wrote:
Here's something I wrote a while ago (minor edits to update for
context) that atte
> 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 useles
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 conf
>> 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 tha
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
> la
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 thi
On Mar 11, 2008, at 3:11 AM, Michael Daumling wrote:
> I think that there is general agreement that
>
> 1) Object.prototype should not be polluted
> 2) Namespaces to add functionality are difficult to handle
> 3) Changing a getter to a setter by adding a new parameter is not a
> good
> idea.
>
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 defi
that behavior in the
spec.
What do you think?
Michael
--
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
Sent: Monday, March 10, 2008 11:33 PM
To: Maciej Stachowiak
Cc: es4-discuss@mozilla.o
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 "judicio
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 i
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 t
>> 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 progr
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
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
> substantiv
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
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 l
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.
>
>
On 3/10/08 5:40 PM, Waldemar Horwat wrote:
> 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
> -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 pra
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,
> t
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
nt: 10. mars 2008 17: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. T
> -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:
> >
> -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:
> >
> 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
On 10/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> Draft 2 of the spec for the Object class. Changelog near the beginning.
The intrinsic toString method returns the concatenation of "[",
"object", the class name of the object, and "]".
There should probably be a whitepace between
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 th
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 … in it early
on, later these appear raw in the source (which displays as an empty
square in Opera and IE8).
And nea
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 Chap
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 does
>> introspect v
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
> > t
On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
> 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
>
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
> -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: Objec
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 confuse
> -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
>
> wh
On Mar 7, 2008, at 7:27 PM, zwetan wrote:
> here some thought
>
> why not have a global utility function, maybe in the magic namespace
>
> SetPropertyFlag( reference:Object, name:*, setflag:int, unsetflag:int
> = 0 ):Boolean
No, sorry -- DontDelete upholds important integrity properties (like,
here some thought
why not have a global utility function, maybe in the magic namespace
SetPropertyFlag( reference:Object, name:*, setflag:int, unsetflag:int
= 0 ):Boolean
the flag could have this logic
| decimal | bitFlag | ReadOnly | DontDelete | DontEnum |
| 0| 000|
On Mar 7, 2008, at 6:30 PM, Yuh-Ruey Chen wrote:
> Interesting and clever proposal. Some thoughts:
>
> - It would become harder to change the enumerability of a property
> (compared to a enumerability method): |obj.prop=obj.dontenum::prop;
> delete obj.dontenum::prop;| That said, I'm not sure ther
Brendan Eich wrote:
> Suppose we had a predefined, open namespace, say dontenum (surely
> not the best name). If you write
>
> obj = {dontenum::cant_see_me: 33}
>
> then
>
> for (i in obj) print(i)
>
> shows nothing. But
>
> obj.cant_see_me
>
> works, because dontenum is always open. No more nee
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
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 enumerab
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrea
> Giammarchi
> Sent: 7. mars 2008 00:25
> To: Es4-discuss@mozilla.org
> Subject: Re: ES4 draft: Object
>
> Garrett Smith wrote:
> > obj = {dontenum length: 10}
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 instea
1 - 100 of 112 matches
Mail list logo
