Good point. Note that you can easily do the same thing without copying, via
prototypes:
https://github.com/rauschma/proto-js
On Nov 13, 2011, at 3:21 , Rick Waldron wrote:
On Sat, Nov 12, 2011 at 7:08 PM, Brendan Eich bren...@mozilla.com wrote:
snip
Let's argue about specifics or we'll get
Neither of them are fit for standardization. Selfish and Prototype are
both incapable of correctly deep copying arrays or objects,
Why does it matter that they don't deep copy? Deep copying is a difficult
problem that needs to be standardized separately. I've personally avoided
deep copying
It depends on what kind of `extends` you mean:
- Inheritance: Even though data being kept in prototypes is rare, it’s usually
better to chain prototypes even when ignoring aliasing problems (no redundant
properties, instanceof works transitively). Performance degradation should be
negligible
On 12/11/11 19:07, John J Barton wrote:
This kind of discussion illustrates my point: JS is not sweet enough
because we are missing core operations for constructing prototypes in
a standard way.
Agreed. I've always thought about JS objects as sets, but it feels weird
that I don't get
Should `extend' copy all the properties? Only the own properties? I feel
`own' properties make more sense.
I agree own makes more sense, we also want to specify whether we want to
extend enumerable properties. Your example does not.
- Defining new objects that extends on the
Except I'm not sure the @private could be made to work without creating
confusing semantics around it, so object literals would still be one step
behind.
As far as I understand @private_stuff would desugar into a name object only
available in scope of the object literal.
The basic idea
On Nov 13, 2011, at 5:08 AM, Jake Verbaten rayn...@gmail.com wrote:
Neither of them are fit for standardization. Selfish and Prototype are both
incapable of correctly deep copying arrays or objects,
Why does it matter that they don't deep copy? Deep copying is a difficult
problem
Hi Andreas,
All good points, and I don't recall any of them being intentional. Your
points seem to suggest changing the semantics such that calling new
fproxy() on a function proxy without a construct trap should perhaps just
simply throw a TypeError.
Now, in the direct proxies design, a missing
A few more thoughts...
On Nov 13, 2011, at 5:08 AM, Jake Verbaten rayn...@gmail.com wrote:
Neither of them are fit for standardization. Selfish and Prototype are both
incapable of correctly deep copying arrays or objects,
Why does it matter that they don't deep copy? Deep copying is a
However having a deep copy mechanism that works without obscure edge-cases
would be great.
Can you be specific? What obscure edge cases have you previously
encountered?
I don't have a list at hand, last time we talked about what it means to
deep copy an arbitary ES-next structure we ran
On Nov 13, 2011, at 7:51 AM, Tom Van Cutsem wrote:
Hi Andreas,
All good points, and I don't recall any of them being intentional. Your
points seem to suggest changing the semantics such that calling new
fproxy() on a function proxy without a construct trap should perhaps just
simply
2011/11/10 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 10, 2011, at 9:03 AM, Tom Van Cutsem wrote:
Regarding property deletion: if an object is implemented as a proxy, and
you would want to delete a property from that object, I'm not sure why you
would want to circumvent triggering the
On Nov 13, 2011, at 11:03 AM, Jake Verbaten rayn...@gmail.com wrote:
However having a deep copy mechanism that works without obscure edge-cases
would be great.
Can you be specific? What obscure edge cases have you previously encountered?
I don't have a list at hand, last time we
On Sun, Nov 13, 2011 at 4:51 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Nov 13, 2011, at 11:03 AM, Jake Verbaten rayn...@gmail.com wrote:
However having a deep copy mechanism that works without obscure edge-cases
would be great.
Can you be specific? What obscure edge cases have you
On Nov 13, 2011, at 9:24 AM, Jake Verbaten wrote:
On Sun, Nov 13, 2011 at 4:51 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Nov 13, 2011, at 11:03 AM, Jake Verbaten rayn...@gmail.com wrote:
However having a deep copy mechanism that works without obscure edge-cases
would be great.
On Nov 13, 2011, at 9:30 AM, Brendan Eich wrote:
The hard cases include:
1. Closures.
2. Proxies.
3. Private names.
4. Internal hidden state.
5. Side-table entries mapped to the object's identity.
In the case of objects implemented by C++ or whatever the host implementation
language
Another thing to consider is whether these functions belong in an iter
module or in a reflect module? I'm leaning towards the letter.
On Nov 12, 2011 12:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 12, 2011, at 11:26 AM, Allen Wirfs-Brock wrote:
The Iterators proposal includes the
On Sun, Nov 13, 2011 at 7:42 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Nov 13, 2011, at 5:08 AM, Jake Verbaten rayn...@gmail.com wrote:
Neither of them are fit for standardization. Selfish and Prototype are
both incapable of correctly deep copying arrays or objects,
Why does it
On Nov 13, 2011, at 10:17 AM, Erik Arvidsson wrote:
Another thing to consider is whether these functions belong in an iter module
or in a reflect module? I'm leaning towards the letter.
Does it matter, apart from the name?
I'd rather have more and more precisely defined modules than one
On Sun, Nov 13, 2011 at 9:34 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 13, 2011, at 9:30 AM, Brendan Eich wrote:
The hard cases include:
1. Closures.
2. Proxies.
3. Private names.
4. Internal hidden state.
5. Side-table entries mapped to the object's identity.
In the case of
On Sun, Nov 13, 2011 at 2:36 AM, Axel Rauschmayer a...@rauschma.de wrote:
It depends on what kind of `extends` you mean:
- Inheritance: Even though data being kept in prototypes is rare, it’s
usually better to chain prototypes even when ignoring aliasing problems (no
redundant properties,
I think this discussion drifted into slightly diff direction.
What I intended to say was that today all major frameworks use same patter to
do subclassing. They all implement different APIs to do the following:
function subclass() {
// init ….
}
subclass.prototype =
On Friday, 2011-11-11 at 18:38 , Brendan Eich wrote:
Having written all this, I will repeat that I like your selfish work and the
exemplar idea
Thanks, that's really encouraging!
___
es-discuss mailing list
es-discuss@mozilla.org
On Nov 12, 2011, at 4:25 PM, Axel Rauschmayer wrote:
There is no requirement that ...r consume 1 element,
It consumes 0 elements above.
Sorry, misread your example -- we seem to agree that if there aren't enough
elements, r gets a fresh empty array.
/be
On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote:
I think this discussion drifted into slightly diff direction.
What I intended to say was that today all major frameworks use same patter to
do subclassing. They all implement different APIs to do the following:
function subclass() {
25 matches
Mail list logo
