Le 28/11/2011 21:00, Jake Verbaten a écrit :
First, if obj already has a non-configurable property 'a', this will
throw
I don't think object extension on a non configurable properties should
be a no op.
It was just an example. I explained later that the setting should happen
only when the
Hi,
Thanks for these notes.
Le 17/11/2011 02:19, Waldemar Horwat a écrit :
Here are my rough notes from today's meeting.
Waldemar
IPR discussions
Test262 status
Do you have any details on this point? A roadmap?
Thanks,
David
___
es-discuss
Le 17/11/2011 12:49, Axel Rauschmayer a écrit :
Map/Set:
Size property should be a getter property with no matching
setter. It's defined on the property.
What is its name? size, count, or length? Decide on es-discuss.
Given that Array already uses `length`, it seems like
Le 17/11/2011 02:40, Mikeal Rogers a écrit :
On Nov 16, 2011, at November 16, 20115:19 PM, Waldemar Horwat wrote:
* Confusion about map. Particularly for people who work on (geographic)
maps.
This is surprising. I might expect confusion with [].map() but not with
geographic maps.
I'm
Hi,
It reminds me of something I was thinking about recently.
A very common pattern in JS is:
(function(global){
var private1 = 'a';
// ...
global.something = 11;
})(this)
block-scoped variables allow a light-weigth version of this pattern:
-
{
let private1 = 'a';
//
Le 10/11/2011 12:28, David Bruant a écrit :
(...)
but i think [traps] should be a right balance between the internal and
external API.
Internal object API:
* getPropertyDescriptor(propName)
* setPropertyDescriptor(propName, desc) (more or less equivalent to the
current [[DefineOwnProperty
Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eichbren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to
Le 08/11/2011 11:54, Tom Van Cutsem a écrit :
About [[SetP]]:
* It seems to me that we've traded a duplicated [[GetProperty]]
call for
a duplicated [[GetOwnProperty]] (Step 1 and 5.a) call on the receiver.
This could be avoided by storing the property descriptor at the
Le 08/11/2011 14:26, Andreas Rossberg a écrit :
On 3 November 2011 23:55, Mark S. Miller erig...@google.com wrote:
If I understood Mark correctly, the features needed for SES are
already part of ES.5 and are shipping in browsers
(and hence don't bear upon future features). Did I
Le 08/11/2011 08:59, Felipe Gasper a écrit :
Hi everyone,
There is a widespread practice of doing this:
-
for (key in obj) {
if (obj.hasOwnProperty(key)) { … }
}
-
The oft-stated purpose for this pattern is to weed out code that comes
from Object.prototype. The
Le 08/11/2011 21:49, Brendan Eich a écrit :
The recommended practice when writing for-in loops in JS today is to
write:
for (i in o) {
if (o.hasOwnProperty(i)) {
/body/
}
}
As said in the thread your forked from, this practice is often
recommended to not enumerate Object.prototype
Le 06/11/2011 15:37, Axel Rauschmayer a écrit :
Claus Reinke could not submit his js-tools discussion group
announcement (interestingly, I could do it for him). And the email I
appended underneath my signature never got through. Can someone
explain the blocking criteria?
I have experienced
Hi Tom,
Thanks for all this work!
Le 07/11/2011 16:54, Tom Van Cutsem a écrit :
Hi,
I wrote up an initial (but fairly complete) draft of a proposed
refactoring of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms
to change the way in which these algorithms climb the prototype
chain:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non-writability,
non-enumerability, private names, const
Le 02/11/2011 16:15, Quildreen Motta a écrit :
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and
their object-lockdown friends, )
Regarding const, it's an optional keyword basically
Le 02/11/2011 17:26, John J Barton a écrit :
On Wed, Nov 2, 2011 at 9:05 AM, Jeremy Ashkenas jashke...@gmail.com wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability, non
Le 02/11/2011 17:05, Jeremy Ashkenas a écrit :
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
non-writability, non-enumerability, private
Le 02/11/2011 19:00, Brendan Eich a écrit :
On Nov 2, 2011, at 10:35 AM, David Bruant wrote:
Le 02/11/2011 18:09, Brendan Eich a écrit :
On Nov 2, 2011, at 4:10 AM, David Bruant wrote:
Another topic:
-
class Monster {
private name, health;
sameName(other) {
return @name
Le 02/11/2011 21:27, Mikeal Rogers a écrit :
On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
This is fine with me and worth the price, but it clearly is not for
everyone.
I don't think I've ever heard an active JavaScript developer, who has
been programming in JavaScript
Le 02/11/2011 22:56, Jake Verbaten a écrit :
I don't think I've ever heard an active JavaScript developer, who
has been programming in JavaScript longer than 6 months, ask for
private class or instance variables.
Your own code:
Hi,
I have just noticed [1], read all messages on this thread and thought
that the JavaScript stack size limit for
Array.prototype.push.apply(firstArray, secondArray); was an
implementation concern rather than anything else and it really sounds
weird to me to add a method just because
Le 01/11/2011 22:17, David Bruant a écrit :
(...)
Regarding implementations of .push, if they can
I meant *can't*, of course.
do as good as a .pushAll
could, then they are just buggy and should be fixed in my opinion.
___
es-discuss mailing list
es
Le 30/10/2011 23:36, Brendan Eich a écrit :
On Oct 30, 2011, at 12:33 PM, Allen Wirfs-Brock wrote:
The object exemplar approach is just like self or selfish, except that it
builds upon features that are already in JS. Specifically, it uses the new
operator instead of a new method and it
Le 31/10/2011 07:20, Brendan Eich a écrit :
On Oct 30, 2011, at 11:11 PM, Brendan Eich wrote:
It ain't 'create' except in a vacuous sense that's also already taken by
ES5 Object.create. It isn't subsuming in my view. refinedBy is closer
but you'll get camelCaps keywords into JS over my dead
Le 30/10/2011 02:35, Quildreen Motta a écrit :
(...)
Are we overthinking classes?
Perhaps the reason for all this thinking about classes come from the
role constructor functions take in the language? I'm a bit sceptical
on constructors and constructor's own properties being that important,
Le 30/10/2011 01:34, Axel Rauschmayer a écrit :
http://wiki.ecmascript.org/doku.php?id=harmony:object_extension_literal_class_pattern
const className = superClass | function(/*constructor parameters */) {
//constructor body
super.constructor(/*arguments to super
Le 30/10/2011 11:35, Axel Rauschmayer a écrit :
I certainly don’t agree that class(-based) languages are easier to
understand. It’s the opposite: Always having to create a class to
create an object is opposed to how humans think: You don’t start with
the abstract, you start with the specific.
Le 29/10/2011 05:45, Brendan Eich a écrit :
On Oct 28, 2011, at 8:23 PM, Axel Rauschmayer wrote:
I’d be sad not to have *class literals* in JavaScript. However, with the new
object literal extensions, things are still much better than in ES5.
Compare: The ES5 version is clumsy.
The ES.next
Le 29/10/2011 05:23, Axel Rauschmayer a écrit :
http://brendaneich.com/2011/10/jsconf-eu/
Brendan Eich in the article:
Much of the Dart http://dartlang.org/ class syntax design looks good
to me. Possibly TC39 can agree to adopt it, with necessary
adjustments. It would still be sugar for
Le 27/10/2011 12:08, Axel Rauschmayer a écrit :
+1. Where the spec is already almost pseudo-code, its readability
would improve if it was, in fact, pseudo-code. But would an extra
interpreter be needed or couldn’t one just implement the ES-262
constructs (execution contexts etc.) in an
Are there tests for this?
David
Le 18/10/2011 21:37, Allen Wirfs-Brock a écrit :
On Oct 18, 2011, at 12:31 PM, felix wrote:
If I define a setter for Array.prototype[0], does [].push invoke that setter?
It's supposed to.
Test code:
!doctype htmlhtmlbody
script
Object.defineProperty(
Wow!
That is quite some work that you've done here. Implementing an ES5
interpreter and contributions to test262.
Well, congratulations and thank you !
David
Le 21/10/2011 07:17, Yusuke Suzuki a écrit :
I got reply from Mr. Fugate, used test262 commad-line runner for lv5,
got some bugs in
Le 19/10/2011 10:57, Andreas Rossberg a écrit :
On 19 October 2011 05:08, David Hermandher...@mozilla.com wrote:
It’s still as easy to create such “virtual” proxies: just pass a fresh
empty object (or perhaps even null?)
Please, make it null. So much more pleasant (and avoids needless
About functions, what is the benefit of having a call trap?
A function proxy (typeof === function) can only be created is the
target contains a [[Call]] internal method (by definition of typeof and
the fact that it's forwarded from the proxy to the target). So, why
having a trap instead of
Hi,
The initial proxy proposal was about to provide proxy as an additional
argument to all traps.
The current proxy has target instead, but still proxy for get and
set traps.
Regardless of the proposal, I have recently come up with a use case [1]
where I expressed the need of passing the
Le 18/10/2011 17:17, Sean Eagan a écrit :
On Tue, Oct 18, 2011 at 6:45 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Hi,
The initial proxy proposal was about to provide proxy as an
additional argument to all traps.
The current proxy has target instead
Le 18/10/2011 17:28, Andreas Rossberg a écrit :
On 18 October 2011 13:45, David Bruant bruan...@gmail.com wrote:
Another alternative would be to do natively what we've been doing in code
which is that when a call is trapped, instead of using the handler, an new
object is created. This object
Le 18/10/2011 21:47, Tom Van Cutsem a écrit :
Hi David,
What you seem to want is the ability to define new kinds of properties
in addition to data and accessor properties. That is beyond the goal
of proxies.
If proxies allow to pass property descriptor attributes other than
Le 17/10/2011 03:29, Andreas Gal a écrit :
(...)
Fixing this just for proxies by stratifying toString, valueOf seems
undesirable. We would grant extra powers to proxies, and suddenly this
following two ways to invoke toString would produce different results
(potentially):
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not meta-methods or
(spec language) internal methods. They do not need their own traps. They are
base-level property accesses.
Well, certainly that's the way the language currently
]] and [[Put]] semantics must be
changed.
Thanks,
David
On Sun, Oct 16, 2011 at 6:00 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 12/10/2011 15:38, David Bruant a écrit :
(...)
_Future work_
1) see how to deal with inherited events
So, I've been
Le 17/10/2011 17:31, Brendan Eich a écrit :
On Oct 17, 2011, at 12:43 AM, David Bruant wrote:
Le 17/10/2011 07:19, David Herman a écrit :
I agree with Andreas. The implicitly-called base level methods are not meta-methods or
(spec language) internal methods. They do not need their own traps
invariants. This in turn enables safe transformation of regular
objects into proxies (Proxy.attach)
- The default forwarding handler becomes a stateless singleton object.
Also, thanks to David Bruant for being an early sounding board and
providing some useful API tweaks.
Cheers,
Tom
Le 17/10/2011 23:52, William Edney a écrit :
(...)
'Proxy.startTrapping()' sounds very interesting... a quick search
didn't turn up anything. Do you have any pointers to discussions,
strawmen, etc.?
Sorry, I forgot the link. It's on the direct proxy proposal:
Le 16/10/2011 22:16, Axel Rauschmayer a écrit :
*From: *David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
*Subject: **Event properties on objects, a proxy experiment*
*Date: *October 12, 2011 15:38:02 GMT+02:00
*To: *es-discuss es-discuss@mozilla.org mailto:es-discuss@mozilla.org
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track of where we are in the discussion about
the additional receiver argument.
I think I just found a pretty important use case for the receiver argument.
Say you want to keep some information about a proxy object in
Le 16/10/2011 23:02, David Herman a écrit :
Forgive me that I've not kept track of where we are in the discussion about
the additional receiver argument.
I think I just found a pretty important use case for the receiver argument.
Say you want to keep some information about a proxy object in
Le 12/10/2011 15:38, David Bruant a écrit :
(...)
_Future work_
1) see how to deal with inherited events
So, I've been working on that. Updated code at
https://github.com/DavidBruant/HarmonyProxyLab/tree/master/EventedObject
(index2.html for test case).
Interestingly, in order to be able
Le 15/10/2011 18:26, Andrea Giammarchi a écrit :
something like this ? ...
My email client says that you're responding to my initial message, but
you may as well be responding to my concern about |this| binding.
I'll assume the former.
(...)
gisted already: https://gist.github.com/1289809
Le 15/10/2011 19:52, Andrea Giammarchi a écrit :
naaa, event is just a placeholder ... most likely is gonna be
var event = @__event__ + Math.random();
Or rather a private name (when this is implemented)?
Or with some WeakMap trickeries?
and most likely that code should be on top with all
Le 14/10/2011 00:22, Allen Wirfs-Brock a écrit :
(...)
Proxy should be able to implement both Array and DOM object semantics (at least
I'm tried to push to make sure that proxies can implement full Array semantics).
I'm confident we're getting there :-)
However, the subclassing story
Le 14/10/2011 22:49, Erik Arvidsson a écrit :
I love it!
I'm glad to create such a reaction :-)
With some minor nits. I feel like [[Call]] should map to dispatch/fire.
Not only do I like this idea, but it may solve a problem I had regarding
|this| binding with inherited events.
in
Le 15/10/2011 01:09, David Bruant a écrit :
(...)
I'll try to find some time to implement the fire as [[Call]] this week-end.
Well, actually, it took me a couple of minutes to implement the things
you mentionned (fire as [[Call]] and a default behavior):
https://github.com/DavidBruant
Le 13/10/2011 17:32, Allen Wirfs-Brock a écrit :
On Oct 13, 2011, at 5:15 AM, David Bruant wrote:
Le 13/10/2011 02:03, Allen Wirfs-Brock a écrit :
...
So far so good
console.log(s instanceof Array); //true
i think that this should be false.
Object.getPrototypeOf(s) is the value
Le 13/10/2011 20:16, Allen Wirfs-Brock a écrit :
On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
On 10/13/2011 09:23 AM, John J Barton wrote:
On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
..
My understanding of |
Le 13/10/2011 21:03, Jay Skeer a écrit :
On 10/13/2011 11:37 AM, David Bruant wrote:
Le 13/10/2011 20:16, Allen Wirfs-Brock a écrit :
On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
On 10/13/2011 09:23 AM, John J Barton wrote:
For me this paragraph is a puzzle. A lot of the problem for me
Hi,
I have started a little experiment and I'd like to share it here.
_Context_
We've been taught that objects are attributes and methods.
Consequently, object clients can inspect attributes (though these are
most often private, but there can be constants) and actively call methods.
However,
Le 12/10/2011 16:42, John J Barton a écrit :
Rather than properties, how about modeling events with promises or await?
Could you describe what you mean and add some code of how it would look
like?
One of the problems I want to solve is to have events as first-class
constructs of objects in
Le 12/10/2011 19:32, John J Barton a écrit :
Is their any hope of solving the GC problem with events? By that I
mean the tedious business of matching removeEventListener to every
addEventListener. If I take an event-thingy from an object, then drop
the reference, the remove is automatic:
Le 11/10/2011 05:48, Cameron McCormack a écrit :
On 24/09/11 8:35 AM, Allen Wirfs-Brock wrote:
Regarding, WebIDL. It seems to me, that it just needs an extended
attribute to specifies which attributes are instance attributes
rather than prototype attributes.
I think it only makes sense to
Le 05/10/2011 10:17, Lasse Reichstein a écrit :
On Tue, Oct 4, 2011 at 6:19 PM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I sent a message here explaining the necessity of a syntax
construct for a reliable bind [1]. There is a need to investingate
(one
If there's a vulnerability with this technique, I need to know that
asap, as I'm about to start writing code that depends on it for
security. So any vulnerabilities you or anyone can point out now will
be greatly appreciated. Thanks.
On Wed, Oct 5, 2011 at 10:24 AM, David Bruant david.bru
Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
Dear All,
while I had the opportunity to ask directly to Brendan Eich this
question, I would like to ask you 5 minutes of your precious time to
understand common concerns from the JS community, summarized under my
point of view in this
Le 04/10/2011 15:43, Kyle Simpson a écrit :
I'm sorry David, I just have to express a dissenting opinion here.
There is no reason to be sorry. As I said at the end, we are different
within the same community. We have different need and views and
consequently, sometimes disagree. That's fine,
Le 04/10/2011 18:51, Mike Samuel a écrit :
2011/10/4 David Bruant david.bru...@labri.fr:
Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
Dear All,
while I had the opportunity to ask directly to Brendan Eich this
question, I would like to ask you 5 minutes of your precious time
Le 29/09/2011 20:10, Brendan Eich a écrit :
On Sep 29, 2011, at 6:54 PM, Geoffrey Sneddon wrote:
On 28/09/11 00:06, Waldemar Horwat wrote:
Should we standardize __proto__ in Annex B?
MarkM + a few others: Yes
Waldemar, Doug: No
Unless we have a definite plan that no ES.Next impl will
Le 24/09/2011 23:50, David Bruant a écrit :
Le 24/09/2011 22:25, François REMY a écrit :
I really think Proxies provides all the functionnalities required to
implement the special border cases where a non-conventionnal behavior
is needed.
I do not think they do on their own, especially when
Le 26/09/2011 14:35, Tom Van Cutsem a écrit :
2011/9/24 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Yet, I still think that not having at the object-level the
equivalent of
what we can do at property-level (with getter/setters changing things
based
Le 24/09/2011 15:33, Jake Verbaten a écrit :
There is no standardized way to create a new function with a prototype
which is not Function.prototype.
I propose Function.create
/*
Creates a new function whose prototype is proto.
The function body is the same as the function
var a3 = o | a; // throws for the same reason
f.__proto__ = o; // prototype changed
a.__proto__ = o; // same
--
David
On Sat, Sep 24, 2011 at 6:03 PM, David Bruant david.bru...@labri.fr wrote:
Le 24/09/2011 15:33, Jake Verbaten a écrit :
There is no standardized way to create a new
the prototype of an object dynamically.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013131.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=642500
[3] http://avocadojs.com/
-Message d'origine- From: David Bruant
Sent: Saturday, September 24, 2011 9:54 PM
To: Xavier
Le 24/09/2011 22:49, Brendan Eich a écrit :
On Sep 23, 2011, at 11:18 AM, David Bruant wrote:
My intuition is that WebIDL imposes getter/setters since it is the only
way in ES5.1 to have a per-instance behavior while intuition would
rather be to describe all properties as regular data
+ redefining Object.getPrototypeOf + adding a
custom Object.changePrototype(object, newProto) (which would /virtually/
change the prototype of a proxy (not a regular object!)), it could be done.
David
-Message d'origine- From: David Bruant
Sent: Saturday, September 24, 2011 10:16 PM
Le 24/09/2011 23:37, Jake Verbaten a écrit :
On Sat, Sep 24, 2011 at 5:03 PM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I'm a big fan of the proto operator proposal, however, as raised
previously this operator relies on the object being created to have
Hi,
In ES5.1 - 13.2.2 is defined functions instances [[Construct]]. As one
can notice, it always returns something of type Object (as per ES5.1 -
8.6). Consequently, a call to new A() always reliably either returns
an object or throws an exception.
Proxies semantics of [[Construct]] states
constraint of [[Construct]] having to return objects (unless types/value
proxies are planned on being objects)
Cheers,
David
I searched the archives but can't seem to find the relevant threads,
still, I'm sure it was discussed here previously.
Cheers,
Tom
2011/9/23 David Bruant david.bru
Le 23/09/2011 17:45, Tom Van Cutsem a écrit :
Hi David,
Even without a |receiver| parameter, a Proxy used as a prototype could
still access the receiver for accessor properties and function-valued
data properties (cf. the last code snippet at
Hi,
Currently, WebIDL states (4.5.3):
There MUST exist an interface prototype object
http://www.w3.org/TR/2011/WD-WebIDL-20110712/#dfn-interface-prototype-object
for every interface
http://www.w3.org/TR/2011/WD-WebIDL-20110712/#dfn-interface defined
Le 24/09/2011 00:35, Allen Wirfs-Brock a écrit :
let instance = Object.create(o);
instance.constructor(/* constructor args */)
This assumes that the new instance will inherit constructor from its
prototype chain (possibly all the way to Object.prototype.constructor (.i.e.
Object).
If you
Hi,
I recently filed a bug on Firefox [1] regarding the fact that i find the
prototype chain of event objects to be messy (half of the problem is
Firefox specific, the other half is standard as per WebIDL). In this
page [2], click anywhere to see a click event prototype chain (top-left
object is
Le 19/09/2011 09:32, Jason Orendorff a écrit :
On Tue, Sep 6, 2011 at 10:59 AM, Mark S. Millererig...@google.com wrote:
[...] Regarding infinite extensible
objects, the only problem I see off the top of my head is: What would
Object.getOwnPropertyNames return?
Hmm. I wonder if this is a
Le 15/09/2011 17:47, Allen Wirfs-Brock a écrit :
On Sep 15, 2011, at 6:49 AM, Andreas Rossberg wrote:
On 15 September 2011 09:10, Brendan Eichbren...@mozilla.com wrote:
On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote:
I would prefer ObjectMap (the keys are restricted to objects).
Le 16/09/2011 14:14, Andreas Rossberg a écrit :
On 16 September 2011 13:52, David Bruantdavid.bru...@labri.fr wrote:
Furthermore, let imagine for a minute that i need an ECMAScript
implementation for programs i write which i know (for some reason) all are
short live and use a maximum finite
Changing the subject to something more relavant.
Le 16/09/2011 15:36, Andreas Rossberg a écrit :
On 16 September 2011 15:17, David Bruantdavid.bru...@labri.fr wrote:
Well yes, but that's part of programming. In practice, all resources
are finite. And the difference between finite and infinite
Hi,
I have come across use cases where i didn't need a Weak/Map/, but rather
a Weak/Set/ which is that I didn't need to set a value. Usually, i set
true but feel like I'm doing something useless. The API I actually
need is:
* .add(obj) (add an element to the set which is one in WeakMaps with
Key orders is supposed to follow the order used in Object.keys (step 6
after The abstract operation /JO/(/value/) serializes an object.)
which is the order of for-in loops which is supposed to be
implementation specific.
However, engines have, in practice, followed more or less the same way
of
Le 07/09/2011 17:35, Mark S. Miller a écrit :
On Wed, Sep 7, 2011 at 6:40 AM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
How about we adapt ideas from the | proposal?
This proposal is only about initializing the prototype. I don't
see what can
Le 06/09/2011 17:59, Mark S. Miller a écrit :
I agree that the spec should clearly state that a non-extensible
object has a finite collection of own properties. Regarding infinite
extensible objects, the only problem I see off the top of my head is:
What would Object.getOwnPropertyNames
Le 06/09/2011 18:15, Mark S. Miller a écrit :
On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
[...]
Regardless, it's a good thing to provide the choice. Regarding
the open
issue (do we default to Object.create or do we
Le 07/09/2011 15:29, Lasse Reichstein a écrit :
On Wed, Sep 7, 2011 at 2:07 PM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
If this is really considered, the problem to solve is to express
an infinite set with a finite representation. RegExps may
Le 07/09/2011 15:38, Tom Van Cutsem a écrit :
2011/9/6 Mark S. Miller erig...@google.com mailto:erig...@google.com
On Tue, Sep 6, 2011 at 8:08 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
[...]
1) Have fix() not just return a property
Le 07/09/2011 15:59, Tom Van Cutsem a écrit :
2011/9/7 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Extensible proxies are not a problem. Non-extensible proxies are
if the specs asks for non-extensible objects (then proxies) to
have a finite set of properties
Le 07/09/2011 17:33, Felipe Gasper a écrit :
Why does Object.keys() not allow, as an option, iterating through
inherited properties?
I do not have the answer to this very question.
However, if you want to iterate through all (own and inherited)
enumerable properties, you can use a for-in loop.
Le 07/09/2011 18:11, Felipe Gasper a écrit :
On 9/7/11 11:08 AM, David Bruant wrote:
Le 07/09/2011 17:33, Felipe Gasper a écrit :
Why does Object.keys() not allow, as an option, iterating through
inherited properties?
I do not have the answer to this very question.
However, if you want
Le 07/09/2011 17:39, Mark S. Miller a écrit :
On Wed, Sep 7, 2011 at 7:10 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
2011/9/7 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
Le 07/09/2011 15:38, Tom Van Cutsem a écrit
Le 06/09/2011 16:12, Tom Van Cutsem a écrit :
2011/9/3 David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr
If i recall correctly, this proposal was on hold because of the fixed
properties proposal (only getPropertyDescriptor I think).
The idea
Hi,
There is a current expectation of objects being a /finite/ collection of
properties, but I don't see this information written anywhere. ES5.1 -
4.3.3 says:
An object is a collection of properties...
Collection is nowhere defined in the spec. The Wikipedia page does not
state clearly
Le 04/09/2011 14:31, Xavier MONTILLET a écrit :
Hi,
I saw in the spec that null is a litteral but typeof null must return
'object'.
There are two things that are different. One is the Null type as defined
in ES5.1 section 8.2 and the return value of typeof null ('object').
This is a
).
Regardless, the dance where you first define a call function, use it to
define Function.prototype.bind, use bind to redefine call to make it
independent of other things is a very interesting move!
Thanks,
David
Michael Ficarra
-- Forwarded message --
From: David Bruant
Le 03/09/2011 00:33, David Herman a écrit :
The proxies page refers to Object.getPropertyDescriptor and
Object.getPropertyNames as the obvious operations that they ought to be, but
also points out that they aren't in ES5. Is there a part of the wiki specs
that explicitly state that they
901 - 1000 of 1196 matches
Mail list logo
