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 4:42 PM, Lars Hansen wrote:
>> That's great. As I wrote elsewhere, the "vote" is non-binding and in
> some instances it will be a bit fuzzy what a row is about; marking it
> "?" or leaving it blank is always an option until things become
> clearer.
I've taken the liberty of
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Maciej
> Stachowiak
> Sent: 7. mars 2008 16:36
> To: es4-discuss Discuss
> Subject: Feature Positions Coming Up
>
> Hi everyone,
>
> I'm not sure what the story is with the feature position
> voting
Hi everyone,
I'm not sure what the story is with the feature position voting, but
Apple will try to record positions of some sort by end of next week.
Also, it might be good to add a JavaScriptCore column to the
implementation section of the spreadsheet.
Thanks,
Maciej
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
<< FIXME Need to check a detail of the type system, namely whether
Vector. is a subtype of Vector. if T is a subtype of U and U is
not *. >>
It shouldn't be. Consider Bar <: Foo, Baz <: Foo:
let baz:Vector. = new Vector.();
let foo:Vector. = baz; // allowed if Vector. is considered a
subtype o
On Fri, Mar 7, 2008 at 7:31 AM, Lars Hansen <[EMAIL PROTECTED]> wrote:
> The chances that the spec will *require* a useful backtrace
> (quasi-fixed format and requirements about which frames may or
> may not be in it, say) or source location information to be
> created for E.p.throw are probabl
> -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} );
> > vs.
> >
> > obj = {length:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Shaver
> Sent: 7. mars 2008 03:34
> To: es4-discuss Discuss
> Subject: Re: ES4 draft: Error classes
>
> 2008/3/7 Ash Berlin <[EMAIL PROTECTED]>:
> > I forget all the problems, but from memory the
2008/3/7 Ash Berlin <[EMAIL PROTECTED]>:
> I forget all the problems, but from memory the main one is that:
>
> MyError = function() {};
> MyError.prototype = Error.prototype;
>
> Doesn't do what you'd expect. And doing
>
> MyError.prototype = new Error();
>
> Is no good since then the filename and
On 7 Mar 2008, at 08:02, Michael Daumling wrote:
This may sound like a stupid question, but...
Adding file and line info to an Error instance seems to be a good
thing.
Should the standard include two read-only properties "fileName" and
"line" that an implementation may choose to fill in duri
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
This may sound like a stupid question, but...
Adding file and line info to an Error instance seems to be a good thing.
Should the standard include two read-only properties "fileName" and
"line" that an implementation may choose to fill in during construction,
and that return, say, the empty string
17 matches
Mail list logo
