ation that object exemplars could not meet).
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thanks. But it is
function exemplar versus object exemplar
and not
constructor exemplar versus prototype exemplar.
Right?
On Oct 31, 2011, at 1:29 , Allen Wirfs-Brock wrote:
>
> On Oct 30, 2011, at 1:12 PM, Axel Rauschmayer wrote:
>
>>> The object exemplar approach is
n = base subsumes function (...args) { ... }
let re = base subsumes /(\w+)\s+(\w)+/g
A bit long, but reads nicely.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailin
One last idea, then I’ll stop my bikeshedding:
I think it helps if it reads well. For example:
const Employee = Person refinedBy { ... }
const Employee = Person subsuming { ... }
const Employee = Person parenting { ... }
const Employee = Person above { ... }
const Employee = Person before { ... }
produce an instance.
I like object exemplar and function exemplar, because they are the more direct
descriptions.
On Oct 31, 2011, at 2:17 , Allen Wirfs-Brock wrote:
>
> On Oct 30, 2011, at 5:47 PM, Axel Rauschmayer wrote:
>
>> Thanks. But it is
>> function exemplar v
_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es
be read as “is
prototype of”.
I’m surprised that the anti-Grawlix faction is so passionate – using a < like
operator for inheritance has a long tradition in theoretical computer science.
Adding a non-grawlix name to Object is a good argument against something
grawlixy, though.
--
D
. Clone means make a twin and mutate. Copy is, well, just a copy
> -- arguably close to clone and one char shorter (so Self chose well). What we
> have with <| is more like "generate a child" -- hence, 'beget'.
Two more ideas:
const Em
like
“proto”: It does not create new vocabulary and has an operator-y feel to it.
let obj = base proto {a: 1, b: 2}
let arr = base proto [p, q, r]
let fun = base proto function (...args) { ... }
let re = base proto /(\w+)\s+(\w)+/g
--
Dr. Axel Rauschmayer
a..
ton
instances, otherwise, you would use “new”).
If people manage to get over their class bias (which is hard, because we have
been exposed to classes so much) then “begets” is a much more natural way of
doing things, because you always directly work with and connect objects.
--
Dr. Axel Rauschm
nging to someone whose
language has not been influenced by Latin, etc.). I’ve heard about beget
(“violence only begets violence”, IIRC) and it’s a combination of two easy
words, so it shouldn’t be too hard to learn. I think it’s too late to remove
the English bias from JavaScript (kudos to
ent" (bad DOM connotations)
>
> Not accurately descriptive but close enough that they have some of the right
> connotations.
> "build"
> "devise"
> "forge"
> "form"
> "invest"
>
> Note that for many non-nat
obj an instanceof Constr?
I think that’s why they work so well. How would you do the same for “beget”?
But “begets” isn’t any better. Maybe “begetting”? The result can indeed be
described as Person begetting an object.
Person beget { ... } => ???
Is beget an imperative here or an infini
t;designate an heir", but I don't
> think English has a word with that meaning. The word "heir" itself is nice
> and short, but I assume that the fact that it is not a verb disqualifies it.
German has a word for it, my dictionary
uman could also be replaced by any
expression.
What is your take on object exemplars?
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mo
t; let f = new F();
> and F inherits from G, then f.foo() will have this.getPrototypeOf()
> === G and that is what super would be? Somewhere I went wrong...
>
> jjb
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discus
ing
> deeper than 2nd level super-calls, then even call-stack is not needed.
>
> See this implementation: https://gist.github.com/1330574#L68 (with
> delete-restore the parent link technique).
>
> Usage level with examples (line 95): https://gist.github.com/1330574#L95
--
D
{
return "b"+super.two();
}
}
let obj = C <| {};
Would obj.one() work? As far as I can tell, your bookkeeping works for one
super recursion only, not for two.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.co
() starts to call this.foo()
(which is perfectly OK if there are parameters involved that prevent an
infinite recursion).
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
prevented
via a parameter)
On Nov 1, 2011, at 19:48 , Jeremy Ashkenas wrote:
> On Tue, Nov 1, 2011 at 2:21 PM, Axel Rauschmayer wrote:
> Invocation: B.describe.call(obj) should return "BA". With your library I
> would expect it to return "BBA".
>
> Yes, it wo
My bad. I thought obj.foo() and this.foo() were different cases, but they
obviously aren’t.
On Nov 1, 2011, at 20:03 , Jeremy Ashkenas wrote:
> On Tue, Nov 1, 2011 at 2:58 PM, Axel Rauschmayer wrote:
>
> Another point to consider: What happens if there are several calls
> super.f
t your search either there or at |this|: look for the *second* occurrence
of property "foo". [optional: optimize non-|this| case]
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
tions about the behavior of your code.
FWIW: here is the code. https://gist.github.com/1331748
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@moz
}
>
> Another problem with skipping var (which we saw in Traceur) was that
> without both var and initializer it looks really strange.
>
> class D {
> z;
> ...
> }
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.co
gt; preference for private, I'm fine stopping with @ for private.
I think the namespacing via this is a feature, it give the code a nice uniform
look:
if (this.foo === other.foo)
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
elf;
> }
I don’t understand. Are you really pointing out something that will cause
difficulty with your proposal or a general problem?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
e using it without any of the
>> other stuff you can even trivially get your minifier to desugar for
>> older browsers.
>> I don't think hard coding the name of the super-constructor is a
>> problem.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschm
nicer.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
FWIW: I’ve picked what I like from the various proposals.
https://gist.github.com/1336846
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
atures then why bother with class at all.
>
> Why not just have
>
> let Monster = Being <| { ... }
>
> This way we don't introduce the class keyword which is confusing and loaded
> with assumptions about what it does and means.
>
> https://gist.github.com/133684
b.mixin(Evil, Scary) <| class {...}
>
> is an important usecase and it is harder to make the syntax work with a pure
> class declaration.
Fine with me, I don’t have any preference in this regard.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/ra
en on your clients don't have to change a thing.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
kind of optional separate module ID.
On Nov 3, 2011, at 20:17 , David Herman wrote:
> Possibly, although it could be tough; I'll keep this in mind as we nail down
> the API details.
>
> Dave
>
> On Nov 3, 2011, at 11:18 AM, Axel Rauschmayer wrote:
>
>> Can loaders
[I’m sending this email for Claus Reinke, because when he sends it, es-discuss
blocks it]
There is a new mailing list for Javascript tool developers,
intended to complement the es-discuss list's language
design and specification topics:
http://groups.google.com/group/js-tools
Please see the a
ES.next:
http://wiki.ecmascript.org/doku.php?id=harmony:modules
What would you want to standardize? It would be great if Node.js adopted AMD,
but at the very latest we’ll have a common standard via ES.next.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
b
jQuery().foo()
> - Everything else here: jQuery.bar()
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
uot;push", hackedPush);
t.add(0);
console.log(stolenArray);
}
Bob(makeTable());
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozil
aside: This problem would go away if we really did distinguish between
accessing a property and accessing a collection element. Then the former would
be done via Object.* methods, while the latter would be done via square
brackets.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rausch
But hackedPush is added to the instance, not Array.prototype.
On Nov 4, 2011, at 18:59 , Allen Wirfs-Brock wrote:
>
> On Nov 4, 2011, at 10:33 AM, Axel Rauschmayer wrote:
>
>> How about:
>>
>> function Bob(t) {
>> var stolenArray;
> Allen
>
> On Nov 4, 2011, at 11:01 AM, Axel Rauschmayer wrote:
>
>> But hackedPush is added to the instance, not Array.prototype.
>>
>> On Nov 4, 2011, at 18:59 , Allen Wirfs-Brock wrote:
>>
>>>
>>> On Nov 4, 2011, at 10:33 AM, Ax
division of functionality:
>>
>> - DOM methods here: jQuery().foo()
>> - Everything else here: jQuery.bar()
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discu
of bleeding edge ES.next
> Module system. jQuery promises that it will not break back compat from one
> release to the next, and when we do, we _hustle_ to get point release bug
> fixes out the door. When 24.6 million[1] sites are using a piece of code -
> because they can trust tha
ct.getProperty() when you want to compute the
name of a property.
- Stricter mode could also restrict [] for arrays to just numbers, including
negative numbers for accessing elements relative to the end of an array.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: ra
that's not doing
> reflection, you should probably refactor.
I agree completely (see also my other email):
- Never use objects as maps.
- Introduce collection classes.
- Try to make arrays fit into the collection framework.
--
Dr. Axel Rauschmayer
a.
force you to use methods such as (the yet to be defined)
> Object.setOwnProperty() and Object.getProperty() when you want to compute the
> name of a property.
> - Stricter mode could also restrict [] for arrays to just numbers, including
> negative numbers for accessing elements relative
could have come from a JSON deserialization.
> The array pattern should not check for 'length' and enforce Array invariants
> that do not apply inherently on the RHS.
>
> /be
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.o
is syntactic sugar for
x = rhs[0], y = rhs[1], z = rhs[2]
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
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?
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home
riginal implementation at Opera.
Very interesting. Still seems orthogonal to the decision whether or not to
coerce the rhs to array (whatever that means). If []= is considered an “array
operator” then coercion seems in line with how other operators behave.
If I wanted to ignore the le
ty names became disjoint in the future. But it’s just an
edge case, anyway.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ul" is a flexible term. Would you recommend using
> that style as a feature?
>
> /Andreas
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t some point. I don't know what the
> blocking criteria is. Maybe an anti-spam trying to be smarter than it is?
That would be my guess, too.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_
t; };
> --
>
> Then, we can do:
> --
> for (var key in obj) {
>if (Object.gave(key,obj)) { … }
> }
> --
>
> …which will still filter out anything in Object.prototype, but will allow
> iteration through inherited prop
ot it, you want to non-destructively modify base_config. It is kind of tricky
to know when to stop traversing the prototype chain, so the more
straightforward solution is to make a copy and modify there or to
non-destructively merge:
https://developer.yahoo.com/yui/3/examples/yui/yui-merg
ad, it should use a
> contextual keyword immediately after 'for':
>
> for own (i in o) {
> body
> }
>
> This is a small thing but it might pay off in the long run.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter:
y access/assignment. It's quite ad-hoc, but works.
>
> The dicts proposal looks nice though.
Modulo what Allen is proposing for [] to keep program domain and data domain
separate. Then dicts can actually get a size() method.
--
Dr. Axe
seems problematic. That’s why I like
Allen’s “data-only-[]” proposal.
I agree with “not interact badly” if there are indeed other use cases.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
__
g up the `this` of the surrounding scope when not invoked as
methods? It seems like that could work in strict mode where no one expects
`this` to have a value.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
ter having seen the
semantics of block lambdas.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
y seeing the word
“function” in object literals – “Isn’t that supposed to be a method? Why is it
called a function, then?”
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
iew process.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ormation they see is correct. For
> example, when I see something by, say, Addy Osmany, Angus Croll, or Nicholas
> Zakas I know that there usually won’t be any errors. It might make sense for
> someone to curate the considerable introductory material that is out there.
> That could be
ow receive `outer' as `this' instead
> of a fresh object? Why would that be the case with the "soft binding"
> described by Axel? Or is this only a counter example for "hard"
> lexical binding of `this'?
>
> /Andreas
> _
ote:
> On Nov 9, 2011, at 3:48 PM, Axel Rauschmayer wrote:
>
> We talked about lexical this for functions long ago (Jan. 2008? at Google
> anyway) and IIRC Mark found a subtler flaw.
>
>
> I think my original example was smaller and more elegant. But the following
> is
scope chain.
On Nov 10, 2011, at 15:11 , Andreas Rossberg wrote:
> On 10 November 2011 14:49, Axel Rauschmayer wrote:
>> getX() is designed for a dynamic `this` (i.e. `this` is an instance of
>> InnerPoint). My proposal would allow an external party to switch to lexical
>> `this
thod(arg1, arg2)
func(arg1, arg2) => func(arg1, arg2)
(The hidden parameter is in angle brackets.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I’m not sure how one can best keep the two styles apart, perhaps @elementGet
should use Object.setProperty() instead of square braces.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-
> I've posted a new strawman proposal for the ideas originally discussed in
> this thread.
>
> http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
I forgot: +1
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
ll allow to replace all
> "(function(global){...})(this);"
IIRC: Block lambdas.
var C = {|| // note the double pipe
let something;
// |this| is the global object
// ...
return something;
}
With a single expression, you don’t even have to return:
var C = {||
Ruby supports it and there we can't
> `return` from blocks, since block wrapping should not be treated as a
> function.
True. My bad. It should work if the return is removed.
Related to the discussion:
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform
--
Dr. Axel
ughly speaking it appears to be
>> "more ambitious than", meaning more effort and more power.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
reate(Array.prototype);
SubArray.prototype.pushAll = function() {
Array.prototype.push.apply(this, arguments);
return this;
}
var s = new SubArray().pushAll(3,4,5);
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_
) than the code below.
>>> function createArraySubclass(proto,...values) {
>>> return proto <| [...values].{
>>> [Array.derivedArrayKey](){return proto<| [ ]}
>>> }
>>> }
--
Dr. Axel Rauschmayer
a...@rauschma.de
hom
= y;
Object.seal(this);
}
Variant 2: allows subtyping, not very pretty.
function Point(x, y) {
this.x = x;
this.y = y;
if (Object.getPrototypeOf(this) === Point.prototype) {
Object.seal(this);
}
}
--
Dr. Axel Rauschmayer
a
gt;return this;
> };
>
> Object.prototype.clone = function ( ) {
>return Object.create( Object.getPrototypeOf( this ),
> Object.getOwnPropertyDescriptors( this ) );
> };
> ___
> es-discuss mailing list
> es-discuss
! It does have one drawback, though: Normally
methods in sub-instances expect the super-instance to be completely
initialized. So performing the super-initialization last is a bit more risky
than performing it first.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.co
ments at the end would be useful. For
example:
[...r, b0, b1, b2] = arr
means: assign the three last elements of arr to b0, b1, b2 (and assign
everything until these elements to r)
It would be nice if r was optional:
[..., b0, b1, b2] = arr
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: raus
ample.
I might also be useful in parameter lists:
function foo(first, ...middle, last) {
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
= 3
d === undefined
I agree with Claus Reinke that naming is tricky: Is destructuring assignment
the reverse of invoking a constructor? Is it a desctructor, then? But that
clashes with C++ terminology.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.c
lass(proto,...values) {
> return proto <| [...values].{
> [Array.derivedArrayKey](){return proto<| [ ]}
> }
> }
@derivedArrayKey would normally be in the prototype, right?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: raus
redefine any
> of the internal methods. All that is needed is to convert their private
> state into private named properties. That's already on my todo list.
And you’d need a way to invoke their constructor as a function, on an existing
instance.
--
Dr. Axel Rauschmayer
a...@rau
nd that the above pretty enough that I could make do without class
declarations.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
t's a good point -- it preserves .constructor, unlike assigning a fresh
> object literal to Person.prototype.
>
> /be
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
to [], the non-rest pattern variables are bound as if
there was no rest element:
[a1, ⋯ , an, b1, ⋯, bm] = [c1, ⋯, cl]
- Otherwise r is bound to an array [r1, ⋯, rk] (with k = l-(n+m)) whose
elements are determined via
[a1, ⋯ , an, r1, ⋯, rk, b1, ⋯, bm]
},
func2() {
}
}
// Allow anywhere: syntactic sugar for
// module name from "@name";
// let strength = name.create(), age = name.create();
private { strength, age }
function Monster(name) {
this .= {
name,
? Suggestions for improvements welcome.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
s mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
hom
course it would be nice if we had the choice of deep vs
> shallow copy within the API.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. A
f you use constructor functions
without any tricks, then scope is an issue:
var private_stuff = name.create(); // it would be nice to have support for a
private section here
function MyClass(stuff) {
this.@private_stuff = stuff; // same as this[private_stuff]
}
MyClass.prototype.method1 = function ()
11-November/017986.html
Sorry to be petty about this – I suggested it in June:
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015084.html
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
Never mind – I misread both Allen’s email and Russel’s gist.
Sorry!
Axel
On Nov 14, 2011, at 21:35 , Axel Rauschmayer wrote:
>> 1. I like the more radical approach (need to ruminate on it more). Usability
>> remains my concern for classes as sugar (the Cordova edition).
>>
r this example, assume the very first
> definition of Point
>
> Finally, you might use class to create a new instance of the same exemplar as
> some other known object:
>
> let mine = new class theirs;
>
> This works the same regardless of whether the value of "theirs" is an object
> or class exemplar.
Is it a good idea to overload this operator?
1. class objectExemplar: “turn the `objectExemplar` into a class”
2. class obj: “get the class of obj”
I would give operator #2 the name `classof` and let `class` only return the own
property value of `constructor`.
--
Dr. Axel Rauschmayer
a...@rau
k by his post, meant to
> reply to it, and now see it in Allen's writeup. Thanks, Russell!
Yes, I feel embarrassed about that. I thought it was about the idea of object
exemplars, but I’ve completely misread both Russell’s gist and Allen’s email.
--
Dr. Axel Rausc
t;constructor" method then it seems both roles would drift further apart. I’m
mainly arguing for a clear separation of concerns.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
es. How about the following one for `class`?
“Retrieve the class (function exemplar) of the operand”
or “go to the nearest class” [in the case of an object exemplar, the
nearest class is inside the exemplar]
But the description is *not* “determine the constructor function that created
let Foo = {};
var f = new Foo();
classof f === Foo // true
The above would not hold for `class`.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-dis
classof f === Foo // true
>
> If new Foo() throws, you won't reach here, and all is consistent.
Sorry, mucked it up (shouldn’t email when tired):
let Foo = { constructor: function() {} }; // or any valid object exemplar
on the RHS, really
var f = new Foo();
class
FWIW: I’ve created a gist that demonstrates static super references (in the
manner that Allen proposes them).
https://gist.github.com/1367052
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
n, if to talk about
> standardization, then the standardized version (whichever it will be) should
> be at _least_ much better than all these libs. Including syntactically.
>
> Cheers,
> Dmitry.
> ___
> es-discuss mailing list
> es-dis
301 - 400 of 582 matches
Mail list logo
