[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
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]
>
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
> -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)
>
>
> >
>> 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
29 matches
Mail list logo
