On Sun, Nov 13, 2011 at 9:49 PM, Brendan Eich bren...@mozilla.com wrote:
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
On Mon, Nov 14, 2011 at 11:48 AM, John J Barton johnjbar...@johnjbarton.com
wrote:
[snip]
Sorry I don't understand. Every function which accepts object
references and embeds its arguments in [[Prototype]] (either in the
return value or the instance created from the return value) faces the
On Mon, Nov 14, 2011 at 10:42 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Nov 14, 2011 at 11:48 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
[snip]
Sorry I don't understand. Every function which accepts object
references and embeds its arguments in [[Prototype]] (either
On Nov 14, 2011, at 8:48 AM, John J Barton wrote:
On Sun, Nov 13, 2011 at 9:49 PM, Brendan Eich bren...@mozilla.com wrote:
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
On Monday, 2011-11-14 at 10:42 , Rick Waldron wrote:
The tests I wrote for Selfish illustrate that it also has this behaviour, but
is more deceiving because you think you're getting new instances.
Hey Rick, I'd be interested to see those tests since it's not supposed to
mutate any arguments
Irakli, pull request for the tests: https://github.com/Gozala/selfish/pull/1
On Mon, Nov 14, 2011 at 2:52 PM, Irakli Gozalishvili rfo...@gmail.comwrote:
On Monday, 2011-11-14 at 10:42 , Rick Waldron wrote:
The tests I wrote for Selfish illustrate that it also has this behaviour,
but is more
You keep bringing in various extend alternatives, but these are separate
from classes. Yes, even in the case when the class body is non-empty: in
that event the elements define properties on the new class prototype
object, which shadow any properties on the base class prototype object.
On Nov 14, 2011, at 12:16 PM, Rick Waldron wrote:
You keep bringing in various extend alternatives, but these are separate from
classes. Yes, even in the case when the class body is non-empty: in that
event the elements define properties on the new class prototype object, which
shadow any
But do they need syntax, or just de-jure codification as built-in library
code after de-facto standardization? I think the latter.
Thanks for the clarification; when that discussion comes, I'll revive my
points.
Rick
___
es-discuss mailing list
On Fri, Nov 11, 2011 at 7:31 PM, Brendan Eich bren...@mozilla.com wrote:
Class syntax is wanted to avoid some method calling boilerplate that's more
verbose, arguably easier to get wrong, and harder to analyze and optimize.
That's it.
Hence, classes as sugar. If you find existing JS sweet
On Mon, Nov 14, 2011 at 11:51 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 14, 2011, at 8:48 AM, John J Barton wrote:
On Sun, Nov 13, 2011 at 9:49 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 13, 2011, at 9:42 PM, Irakli Gozalishvili wrote:
I think this discussion drifted into
On Nov 14, 2011, at 2:07 PM, John J Barton wrote:
Irakli proposes a function; you are discussing classes. So perhaps
rather than agreeing with Irakli you are drawing a parallel: you like
the object created by Irakli's extend() and wish to take that into the
class discussion?
Irakli and I are
On Mon, Nov 14, 2011 at 2:27 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 14, 2011, at 2:07 PM, John J Barton wrote:
Irakli proposes a function; you are discussing classes. So perhaps
rather than agreeing with Irakli you are drawing a parallel: you like
the object created by Irakli's
On Nov 14, 2011, at 3:16 PM, John J Barton wrote:
I'm not suggesting such an API. In fact I am suggesting that such an
API is not always possible. If the syntax is
class D : B { pList }
and requires that B be an identifier and pList list of properties,
then the API would have to have
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
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 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
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 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 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() {
On 11/11/11 23:44, John J Barton wrote:
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eichbren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
I mean Object.extend does not exist.
Irakli is using
On Nov 12, 2011, at 4:38 AM, Quildreen Motta wrote:
On 11/11/11 23:44, John J Barton wrote:
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eichbren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
I mean
On Sat, Nov 12, 2011 at 11:53 AM, Brendan Eich bren...@mozilla.com wrote:
On Nov 12, 2011, at 4:38 AM, Quildreen Motta wrote:
On 11/11/11 23:44, John J Barton wrote:
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eichbren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Let's argue about specifics or we'll get nowhere. Do you think Irakli's
selfish.js extend (
https://github.com/Gozala/selfish/blob/master/selfish.js) is the way to
go, or Prototype's quite different form?
I'd personally prefer Prototype's extend because it actually extends an
object
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 nowhere. Do you think Irakli's
selfish.js extend (
https://github.com/Gozala/selfish/blob/master/selfish.js) is the way to
go, or Prototype's quite different form?
On Sat, Nov 12, 2011 at 4:15 PM, Jake Verbaten rayn...@gmail.com wrote:
Let's argue about specifics or we'll get nowhere. Do you think Irakli's
selfish.js extend (https://github.com/Gozala/selfish/blob/master/selfish.js)
is the way to go, or Prototype's quite different form?
I'd personally
Hi,
I have posted this to the long thread of Minimalist Classes, but since I have
not got any response, I assume it got lost into a long discussion. So I thought
I'll give it another try on fresh thread.
I do really liked direction that Jeremy tried to push classes to, but still I
don't
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
http://wiki.ecmascript.org/doku.php?id=harmony:classes
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue
On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
http://wiki.ecmascript.org/doku.php?id=harmony:classes
Maybe, but I think
On Fri, Nov 11, 2011 at 4:31 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 11, 2011, at 4:09 PM, Irakli Gozalishvili wrote:
Thats exact port of proposal that Jeremy wrote here:
https://gist.github.com/1329619
I could write add examples from the classes proposal if that wolud help:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
Irakli is using Function.prototype.extend, not something like PrototypeJS's
Object.extend.
Similar but not identical functions
are widely used. We would like a standard form built-in
What I'm suggesting is to sugar current patterns, without adding new syntax
similar to how Funciton.prototype.bind was added. And maybe in next iteration
add special syntax if it still we be wanted. It's just so much easier to fix
`Object.extend` if it will end up to be a wrong fit than change
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
I mean Object.extend does not exist.
Irakli is using Function.prototype.extend, not something like
On Nov 11, 2011, at 5:02 PM, Irakli Gozalishvili rfo...@gmail.com wrote:
What I'm suggesting is to sugar
Sugar usually means new syntax, not methods, but no worries.
current patterns, without adding new syntax similar to how
Funciton.prototype.bind was added.
That ES5 addition was years
47 matches
Mail list logo
