t;
> myClass.prototype.getTest = function() { return this[test] }
>
> Is the above perfectly valid?
No, ES.next would complain about the undeclared variable `test` (variable
scope, not object). The closest you can get to simulating is by using strings
with UUIDs. That avoids t
compiling into ES3/5 you could get away
> with not attaching some .__privates__ property to the object and instead just
> put a closure around the definitions.
>
> Thanks ahead of time!
>
> Matthew Robb
> _______
> es-discuss maili
os(obj) {
var chain = [];
while (obj) {
chain.push(obj);
obj = Object.getPrototypeOf(obj);
}
return chain;
}
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
__
easily.
>
> You beat me to it! Programs of even moderate size and complexity require
> abstraction. Arguably that's what real programmers do. If "library author"
> means "abstraction creators" then those are exactly the people we want to
> better supp
post as not at all that strong as it may
> look.
Those names are not important, what matters is the list of use cases and their
analysis. Do you only disagree with the names or also with the analysis?
There are some things that normal developers never do, for example: patching
built-ins.
has taken on some of definition’s responsibilities.
--
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
Those are the labels that can be used e.g. with break and continue. Not names
of properties in an object literal.
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
On 09.08.2012, at 20:15
we are missing the clarity that we have with
variables: You can’t assign to an undeclared variable (in strict mode). With
properties, assignment “auto-declares” if there is no own property and no
setter. So things are less clear.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home
Or are there other common pitfalls?
--
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
one? 1 would be the default, 0 or -1 could be used for: “the complete
prototype chain”.
Loosely related: I recently looked at _.extend and was surprised that it didn’t
copy non-enumerable properties (as far as I can tell, impossible pre ES5) and
that it included all inherited properties. OTOH, if
structors put all instance data in the same object, so you
already have an automatic flattening.
--
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 es-discuss.
I stick to spec terminology as much as possible, but some things are beyond the
scope of the spec (such as IIFE). Then I just want to make sure that there
isn’t something good already in use before I make up my own words.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
tw
Makes sense! Thanks!
On Aug 6, 2012, at 23:29 , Brendan Eich wrote:
> Rick Waldron wrote:
>> On Monday, August 6, 2012 at 4:18 PM, Axel Rauschmayer wrote:
>>> Will that function still be added, or will its work (setting up [[Home]]
>>> and [[MethodName]]) be done v
may be taken to mean "primitive,
> not reference (object)."
Got it. Wanted to avoid NIH in my writings, but will try my best to keep my own
terminology consistent.
I thought value objects came from “compare by value”, but then I am still
making Rick’s point.
--
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
for
>> the term IIFE.
> Ben Alman coined this, not the spec.
You are making my point!
Or are you saying that this kind of discussion (not *directly* related to the
spec) is off-topic? But where else can you discuss this?
--
Dr. Axel Rausch
scalar, whereas "data" is accurately vague.
My understanding:
- Method: a property whose value is a function.
- Data property: a property that is not a method or an accessor (getter,
setter). Example: “ES.next classes don’t let you directly create data
properties in prototypes”.
- Value
Will that function still be added, or will its work (setting up [[Home]] and
[[MethodName]]) be done via Object.defineProperty? I couldn’t find anything in
the draft.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
term IIFE.
On Aug 3, 2012, at 10:34 , Alex Russell wrote:
> There is a long history of TC39 naming things for internal use and those
> names never escaping to the common lexicon. I'm not sure it's a thing we need
> to (or even should) weigh in on via the spec.
--
Dr.
On es-discuss, I’ve seen the term “data properties” used for named data
properties that are not methods.
In this light: wouldn’t it be better to rename named data properties to named
value properties?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
is is a generic DSL embedding mechanism, where you can
> escape back into the host language from holes in the guest language. The
> thing to the left of the first backquote, more than anything else names the
> guest language being embedded. (FWIW, in E we call in It the quasiparser
ki.ecmascript.org/doku.php?id=strawman:dicts
>
> /be
>
> Axel Rauschmayer wrote:
>> As an example, a template string call site ID would be constructed as
>> follows:
>>
>>const callSiteId1234 = do {
>>let literalParts = ['lit1\n&
> On Aug 2, 2012, at 4:08 PM, Axel Rauschmayer wrote:
>
>> Lately, the es-discuss filter has been very picky about my emails: 3 out of
>> 5 were rejected in recent weeks and are still held up somewhere.
>>
>> What can I do? Even telling es-discuss-owner@… about it doesn’
Thanks. Will try to avoid the words Viagra and casino in my posts. ;-)
On Aug 3, 2012, at 6:45 , Brendan Eich wrote:
> Trying to whitelist you. Your posts look like spam to postini!
>
> /be
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/raus
rts
};
How about the following abbreviation?
const callSiteId1234 = ['lit1\n', ' lit2 ', '', raw: ['lit1\\n', ' lit2 ',
'']];
Not sure it’s a frequent-enough use case, though. Mustache would be nice here,
or one could use
On Jul 29, 2012, at 6:09 , Brendan Eich wrote:
> Axel Rauschmayer wrote:
>> A case could be made that Foo.[[prototype]] should be Object and not
>> Function.prototype. Then the prototype hierarchies of classes and their
>> prototypes would be fully symmetric. The reason
r".
>
> However, in talking about the syntactic forms it seems awkward to say "a
> template string with a handler" or a "handled template string". In those
> situations it may flow better to refer to the expression that provides the
> handler value
plate" to emphasize that it was a
> template that was expressed as a string rather than a template for a string.
> That may be too subtle of a distinction. At the TC39 there were some
> concerns that simply "template" was too general and might cause confusion
> relativ
to this approach.
Nice. I’d let the html handler do the join, then it’s even shorter. That is: If
a substitution is an array of strings, it joins, otherwise it coerces to string.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
_
om/g_marty/status/231404856492036096
> [2] https://twitter.com/mathias/status/231418712580845568
> [3] http://kangax.github.com/es5-compat-table/non-standard/
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.moz
word" is not the right word.
Suggestions for better terms welcome. Property parameters? Inside a parameter
object?
> Named parameters were part of original ES4/JS2:
>
> http://web.archive.org/web/20030216220908/http://www.mozilla.org/js/language/js20-2002-04/core/functions.html#param
Lately, the es-discuss filter has been very picky about my emails: 3 out of 5
were rejected in recent weeks and are still held up somewhere.
What can I do? Even telling es-discuss-owner@… about it doesn’t seem to work,
any more.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
/2011/11/keyword-parameters.html
--
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
f the ES.next parser handling nesting for you.
[1]
http://www.nczonline.net/blog/2012/08/01/a-critical-review-of-ecmascript-6-quasi-literals/
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-dis
eless it's hard to find
> time to write the rest.
>
> On Thu, Aug 2, 2012 at 4:02 PM, Axel Rauschmayer wrote:
>> What’s the best material for reading up on the “override mistake”?
>> This?
>> http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistak
o remain unchanged in this regard.
>
>
> --
>Cheers,
>--MarkM
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Dr. Axel Rausch
A case could be made that Foo.[[prototype]] should be Object and not
Function.prototype. Then the prototype hierarchies of classes and their
prototypes would be fully symmetric. The reason that isn’t done is so that a
class is an instance of Function, right?
Axel
--
Dr. Axel Rauschmayer
a
t;{}". Perhaps JSON.stringify(undefined) should, however, return "" -- in my
> view, this would make more sense.
>
> On 16/07/12 10:48, Axel Rauschmayer wrote:
>> ... returns undefined. Shouldn’t it be "undefined"?
>>
>> --
>> Dr. Axel Ra
... returns undefined. Shouldn’t it be "undefined"?
--
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/l
s as much as you want! :)
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
Home: rauschma.de
Blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Right. :-)
There is indeed some clever module stuff out there. IIRC, Racket, née PLT
Scheme, goes even further than ML. Newspeak is interesting, too.
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http
ork around not having functions (via
static methods), a bit like JSON, Math, et al.
--
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://ma
side (at the callsite) much, in my
> experience. Dave may be seeing other sources, but it's extremely rare in my
> experience to see
>
> foo(arg1 || callers_idea_of_default_arg1_value);
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/
>> I was mostly concerned about concise methods.
>
> For most cases, you just want [[Put]]. And I favor thin arrow for concise
> standalone methods/constructors.
How about the following use case? Adding a method with a super-reference to an
existing object.
--
Dr. Axe
o :, but with [[Put]].
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
Home: rauschma.de
Blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
vaScript how it
should be”. So there must be a rationale behind making it fail silently in
non-strict mode.
I personally don’t mind too much, because the object is frozen either way,
things just fail much later in non-strict mode.
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
> Axel Rauschmayer wrote:
>> I was under the impression that ECMAScript.next was going to perform arity
>> checking. But looking at the proposals and the draft spec, it doesn’t look
>> like it.
>
> How would that work? It's impossible under 1JS.
>
>> I
rgive brevity and typos.]]]
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com
On 24.05.2012, at 19:58, Allen Wirfs-Brock wrote:
> Ecma International now hosts a normative HTML copy of Ecma-262, Edition 5.1
> The ECMAScript Language Specification. T
perform arity checking
only in the presence of parameter default values and/or rest parameters.
Conditionally switching it on (e.g. via a pragma) does seem an option, though.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
hink it is up to Waldemar and supporters of his
> requirements to come up with concrete proposals how these things can
> fit into ECMAScript. (Thanks Russel for starting this thread.)
--
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
g to push them into another array.
>
>
> Regards
> --
> Irakli Gozalishvili
> Web: http://www.jeditoolkit.com/
>
> On Thursday, 2012-05-24 at 18:00 , Axel Rauschmayer wrote:
>
>> On May 25, 2012, at 2:42 , Irakli Gozalishvili wrote:
>>
>>> At the m
lans for
a module of iterator tools.
--
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
would be non-writable, but data would be. As I indicated,
> private names can be used to protect against unwanted mutation.
What function (or equivalent operation) would [[Construct]] apply to an
instance after initialization? Object.seal() or Object.freeze()?
--
Dr. Axel Rauschmayer
a...@rau
minimal impact, and does not
> affect future friendliness. Other additions like private properties and
> static methods, for example, would easily fit before ES6 is finalized or as a
> future. enhancement.
>
> - Russ
> ___
> 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
Maybe there is a ES.next feature which allows subclassing javascript arrays
> in another way then mentioned above?
>
> Regards,
>
> Henri
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://ma
:
> The "weak reference" semantics needs to apply to the entire collection in
> order to avoid key/value circularity induced leaks
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo
pushing low-level JS performance and language
> extensions!
I like that they can be introduced in a stepwise fashion (whenever that may
be...): Numbers first, user-defined value object types later. Numbers should
complement the binary data proposal nicely.
--
Dr. Axel Rauschmayer
a...@rau
and always use
semicolons. And they can afford to initially ignore == and always use ===. I
use such rules for myself, too. It allows me to stay sane w.r.t. to some of the
details.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
__
. "number"
5. "string"
6. "value object"
7. "reference object"
That would cover my use cases.
--
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
> Axel Rauschmayer wrote:
>> Until ES.next, I’ve stuck to the simple rule: Always use `new` when you want
>> to create an instance. That avoids confusion when it comes to functions such
>> as String and Boolean: I like using them to coerce values.
> User-defined constru
” it.
- Should there be alternate, possibly less confusing, ways of coercing values?
ToPrimitive() would certainly be nice to have.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es
);
}
}
Tree.prototype[iterator] = iter;
On May 10, 2012, at 23:22 , Erik Arvidsson wrote:
> On Thu, May 10, 2012 at 2:16 PM, Axel Rauschmayer wrote:
>> function* iter() {
>>
>> if (this.left) {
>>
>> yield* iter(this.left);
>
> I'm con
if (this.left) {
>> yield* iter(this.left);
>> }
>> yield this.label;
>> if (this.right) {
>> yield* iter(this.right);
>> }
>> }
>>
>> Tree.prototype.visit = visit;
>> Tree.prototype[itera
* iterGen(this.right);
}
}
Tree.prototype.visit = visit;
Tree.prototype[iterator] = iterate;
On May 10, 2012, at 21:32 , Brendan Eich wrote:
> Jason Orendorff wrote:
>> On Wed, May 9, 2012 at 2:07 AM, Axel Rauschmayer wrote:
>>> Nice. It took me a few moments to
would like to understand other real use cases
> where cross-frame type testing is needed. Does anybody have any?
--
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
(underscore) or build something new.
>
> [...]
>
> -Mikeal
>
> On May 9, 2012, at May 9, 20124:46 PM, Axel Rauschmayer wrote:
>
>> I’m seeing quite a bit of anti-TC39 sentiment out there and I don’t think
>> it’s fair. Some examples (paraphrasing):
>>
>
modules change anything? Are module instances shared between windows? Will
there be a unique way of identifying types? Are there any other ideas for
making the cross-window situation simpler?
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.
strategy for doing so, but I’d love to read
more about it.
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
ally, one could throw an exception if there is an instanceof check
whose lhs and rhs are from different contexts (failing fast, preventing obscure
and hard-to-debug errors).
--
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
makes sense:
this.left.@iterator()
On May 9, 2012, at 5:02 , Erik Arvidsson wrote:
> On Tue, May 8, 2012 at 4:24 PM, Axel Rauschmayer wrote:
>> Cool. Like this?
>
> Yup.
>
> http://code.google.com/p/traceur-compiler/source/browse/test/feature/Yield/Tree.js#13
>
>
e “new typeof” is to be about classifying primitives and distinguishing
primitive values from objects then I would make it return "object" for all
non-primitive values (including functions).
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
both.
Or do you propose returning functions for objects and strings for primitives?
E.g.:
switch(type(x)) {
case "null": // x is null
...
break;
case "string": // typeof x === "string"
...
break;
case String: // x instanc
012, at 1:20 , Erik Arvidsson wrote:
> You can use yield* here.
>
> On May 8, 2012 4:12 PM, "Axel Rauschmayer" wrote:
> The following generator produces an iterator for nested arrays. Is this the
> best way to do recursion? Doesn’t seem terribly elegant.
>
>func
ext()
[object StopIteration]
--
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
could pretty easily add a new library function:
>
> import type from "@std";
> console.log(type(null)) // "null"
>
> I'd support that.
>
> Dave
>
> ___
something like this even possible?
>
> Rick
>
> ___
> 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/raus
>global object properties are only be created via explicit reference to
> global this
>
>No Global Object
> Global object is undefined
> all ES top level declarations (including var/function) create binding
> in Top Lex
>
>
> Thoughts? I
> Biju
> ___
> 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
need a way to declare
whether an argument is expected to have dynamic or lexical this.
Possibly
On Apr 29, 2012, at 20:01 , Brendan Eich wrote:
> If so then there is no need for any isArrowFunction or
> isFunctionThatBindsOrIgnoresThis predicate.
>
> /be
>
> Axel Rauschma
ard not
> to picture chaos. (and how do you shim => anyway?)
Right. I think you can still tell a simple story to beginners while supporting
thin arrow or (this, ...) => {} for legacy software.
But I’d hope that the old code can be cleanly separated and that a new coding
style will be supp
With “rules”, I don’t mean rules in the sense of the language spec, but rather
rules for teaching the language to newcomers.
On Apr 29, 2012, at 10:28 , Brendan Eich wrote:
> Axel Rauschmayer wrote:
>> I am not saying that the transition from the old rules to the new rules will
>&
Correction:
Some code such as `forEach` implementations that previously needed to use
`call` to simulate lexical scoping don’t need the `thisValue` parameter for
arrow [was: array] functions.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog
IMHO. Library code might need to go to extra lengths to help normal developers
with the transition (error messages, different behavior, tool functions, etc.)
and – to be explicit – might need a predicate such as `isArrowFunction` (which
should only ever be used under the hood and thus would not in
:
>
> On Apr 24, 2012, at 3:30 PM, Axel Rauschmayer wrote:
>
>>> B. add expression bodies to method shorthands, don't add skinny arrow
>>>
>>>(-) Loses the flexibility of shorthand syntax for assigning to an
>>> existing objec
? You’d have
to invoke a defineMethod() somewhere along the way.
--
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
box() this._value,
setbox(v) this._value = v
}
--
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
is easily confused.
>
> Hope that helps
>
> Rick
>
>
>
>
>
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-dis
thod() invokes the actual method.
Hence, in addition to getters and setters, we would have "callers". If a
property doesn’t have a caller then obj.method() would first invoke the getter
and then try to call the result.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twit
> Using `=>` but being forced to using `function` anytime I want dynamic this
> just doesn't work.
That may be the crux of the matter. I’d say: In new code, use a method
definition any time you want dynamic `this`. In old code, use a function
expression.
--
Dr. Axel
functions) and method definitions (methods), one
> will automatically do the right thing.
>
> Thats three types of functions now. Our legacy code is going to be confused.
A definite possibility. However, the only problem I can see is a function
expecting to pass `this` to a
> On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer wrote:
> Counter-question: Isn’t it clear when you create a function whether it is
> going to be a non-method function or a method?
>
> It's clear to the implementer - Its not clear to a function that gets it as
&g
ut then you need to
convert it to a non-method function, anyway (e.g. via bind()).
--
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
this =
undefined is bearable for old-school non-method functions, but switching to
lexical this will lead to many hard-to-debug errors.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
bjects @call and
> @construct properties.
>
> This also simplifies direct proxies by allowing any proxy to have call and
> construct traps.
>
> Comments welcome.
>
> /be
> ___
> es-discuss mailing list
>
> On Tue, Apr 10, 2012 at 4:01 PM, Axel Rauschmayer wrote:
> What is a good term for functions that don’t have/use dynamic `this`?
> “Non-method function” defines them by what they aren’t, I would like a
> positive definition. I’ve considered the term “pure function”, but the
>
function myDefineMethod(obj, propName, func) {
Object.defineProperty(obj, propName, {
get: function () {
// TODO: memoization
return func.bind(this);
},
invoke: func
});
}
This might clash with the proxy protocol and
ertain amount of purity and
> correctness to it, I just don't think its practical.
>
> - Russ
>
>
> Allen
>
>
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.d
notation:
- Read: bind `this`
- Write: apply defineMethod to the argument (not sure about this one)
- Call: same as before
I have no idea how this would fit into the current semantics, so it might be a
silly idea, but it would eliminate a common source of bugs.
--
Dr. Axel Rauschmayer
a
being derived from “partial
application”.
On Apr 11, 2012, at 18:44 , Allen Wirfs-Brock wrote:
>
> On Apr 11, 2012, at 7:12 AM, Peter van der Zee wrote:
>
>> On Wed, Apr 11, 2012 at 1:01 AM, Axel Rauschmayer wrote:
>>> What is a good term for functions that don’
On Apr 11, 2012, at 12:37 , Alex Russell wrote:
> On Apr 11, 2012, at 1:02 AM, Allen Wirfs-Brock wrote:
>
>> On Apr 10, 2012, at 4:01 PM, Axel Rauschmayer wrote:
>>
>>> What is a good term for functions that don’t have/use dynamic `this`?
>>> “Non-method
object
> - Method: A function that has a dynamic this (or super) dependency.
> - Callback: A function that does not have a dynamic this dependency.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
501 - 600 of 1233 matches
Mail list logo
