Re: Promise.cast and Promise.resolve
Resolving this would be much appreciated. Gecko recently turned on Promises in our nightly builds, and already branched to our aurora builds. I believe Chrome is in a similar situation. Chrome has shipped Promises, i.e. they are enabled by default on the current stable Chrome. So the situation is more serious for us. - Promise.cast is renamed to Promise.resolve (remove old Promise.resolve) - Keep then, reject chain (NOT DEFER, reject!) - Renaming .cast thus removes over-wrapping (always-wrap) deoptimization in old Promise.resolve Sorry for knowing little about ES consensus, is this the final decision? Will you change it again? Thanks, On Wed, Feb 5, 2014 at 1:53 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jan 29, 2014 at 7:33 AM, Kevin Smith zenpars...@gmail.com wrote: It is, actually, more simplicity. The concept of `Promise.resolve` and `Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.: they represent orthogonal concepts, not complected). `Promise.cast` and `Promise.then` may be, arguably, *easier* to work with, from a user POV, since you don't need to make as many choices. I would argue that it would make more sense to write `cast` and `then` in terms of `resolve` and `chain`, however. But this seems to have already been decided. It does make more sense, and from my point of view it's not decided. What is decided is the AP2 design. That is: 1) promises are fully parametric and, 2) `then` recursively unwraps the *input* to its callbacks. For the sake of coherency (aka conceptual integrity), `then` needs to be written in terms of `chain`. This issue needs to be resolved ASAP, however, since promises are making their way into engines now. Resolving this would be much appreciated. Gecko recently turned on Promises in our nightly builds, and already branched to our aurora builds. I believe Chrome is in a similar situation. / Jonas ___ es-discuss 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
Re: Promise.cast and Promise.resolve
On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote: Sorry for knowing little about ES consensus, is this the final decision? Will you change it again? Yeah, some clarity would be nice. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=966348 on Gecko when the news broke. Mozilla can probably still make things in order before promises hit stable. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On 5 February 2014 11:17, Mark S. Miller erig...@google.com wrote: At the end of Sept mtg, my memory of the state on entry to the meeting agrees completely with Domenic's. On exit, my memory is a) We had agreed to promote both the .then level and the .chain level to ES6. (This is probably the biggest disagreement among the memory of the attendees.) FWIW, I agree, but it's clearly at odds with Dominic's interpretation of that meeting. b) At the .then level, we agreed essentially to promises-unwrapping as it was at the time, which did one-level unwrapping of the output side of .then by use of internal properties. (Or what Domenic now characterizes as by magic.) c) Domenic and Allen had talked about subclassing, and Domenic came up with a nice subclassing proposal that kept this by magic unwrapping. After the September mtg Yehuda did not attend the end-of-Sept mtg, and afterwards rejected the by magic unwrapping as hostile to subclassing goals I have yet to understand. Domenic responded by changing the output unwrapping of .then to use .then, which, as Kevin correctly points out, broke the AP2 consensus. However, at my urging, Domenic initiated a private thread with the main .chain level advocates, including IIRC Andreas, Sam, and Tab, to see if any objected to the switch to .then doing unwrapping by use of .then. I was privately shocked that none did. At this point, perhaps I did the community a disservice by staying silent, and not pointing out more forcefully to the .chain advocates why they should object to this switch. But since * they were not objecting, * the switch only harmed properties that they care about and none that I care about, * we knew of no way to restore the AP2 consensus and also achieve Yehuda's subclassing goals I did stay silent until this problem was independently noticed by Kevin and brought to my attention and (at my urging) Domenic's attention as well. To clarify, I may not have reacted directly (probably a mistake, but I considered .then to be too big a bag of magic anyway to really care about it per se, as long as flatMap/.chain was available as a clean and well-understood primitive, which I assumed would be the case -- as did Sam and Tab, I suppose). However, this question actually triggered me to have a closer look at the state of the spec (again), the outcome of which was my proposal for a refactoring. That refactoring based .then on .chain and pulled it from any of the core logic, thus avoiding the problems you seem to be alluding to, while still allowing subclassing. Dominic adopted much of that refactoring for the spec, but left out the central part, namely .chain and its use, because he assumed it wouldn't be relevant for ES6. THE BIGGER ISSUE Unfortunately, just as Yehuda was not there in September and did not agree to the consensus then, Andreas was not there on Thursday of January and (above in this thread) does not agree to that consensus. This indicates a different failure mode we should be concerned about. Not everyone is at every meeting. If anyone absent from any meeting can veto the hard-won consensus achieved by those who did attend, it is hard to see how to make progress. OTOH, without this dynamic, we might proceed despite strongly held objections, which really is not consensus. Only our insistence on true consensus has saved us from prior disasters like ES4. I really don't know what to do about this. I agree that this is a general issue moving forward. We actually had several occasions where consensus flipped forth and back between meetings, which is a problem, especially when implementers want to move ahead with features. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async decision making (was Re: Promise.cast and Promise.resolve)
On 5 February 2014 12:10, Alex Russell slightly...@google.com wrote: On Wed, Feb 5, 2014 at 12:00 PM, Brendan Eich bren...@mozilla.com wrote: I'd rather we keep separate and conflict-prone APIs in separate objects, though. I'd rather we acknowledge that Promises are a library de-facto quasi-standard we are trying to codify, not green-field work where we can start over or do both. Excited to hear someone else recognize this reality. Alex, could you clarify your position a little bit? On one hand, you have repeatedly complained about the current spec, on the other hand you seem to be arguing for just adopting DOM reality. Can you say what this should consist of, from your point of view? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
However, this question actually triggered me to have a closer look at the state of the spec (again), the outcome of which was my proposal for a refactoring. That refactoring based .then on .chain and pulled it from any of the core logic, thus avoiding the problems you seem to be alluding to, while still allowing subclassing. For reference (since it was mentioned), my counter-proposal is here: goo.gl/3XzX9R and is basically just a minimization of Andreas's work. The only substantial difference is that `Promise.defer` is used as the subclass create a default tuple contract. (And less substantially, nominal type-testing is performed using a built-in symbol, rather than using internal slots.) I agree that this is a general issue moving forward. We actually had several occasions where consensus flipped forth and back between meetings, which is a problem, especially when implementers want to move ahead with features. If I may interject some opinions on process... I'm not sure how this fits in with the new post-ES6 process, but from this one outsider's point of view: - A formal set of design goals should be completed and agreed upon before design work is begun. The design goals form the basis of measurement and the champion(s) must be bound to them at all times. Any changes to the design goal document must be carefully reviewed in order to prevent churn. A detailed change-log is an obvious requirement. - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. On a side note: it seems to me the the existence of the design champion, who by definition is deeply invested in the design process, implies the existence of its dual: the anti-champion, who is detached from the details of the design work and provides a vital holistic perspective. In a hierarchical organization this role would be taken on by the chief architect, I suppose, but in a committee you don't have one of those. : ) I feel that I have stepped into this role on occasion, much to the chagrin of various champions (apologies to Sam, Dave, and Domenic for any and all heat - nothing personal of course). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise.cast and Promise.resolve
On Fri Feb 7 06:50 AM, Anne van Kesteren wrote: On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote: Sorry for knowing little about ES consensus, is this the final decision? Will you change it again? Yeah, some clarity would be nice. From a user perspective, can someone explain what chain() does? Recently hit an issue with Q.all() vs serial execution of promises: https://github.com/jbondc/cordova-plugman/commit/ad2c74b3344c8899e8ede12827f7ca4637a01b6f#diff-9f06c51911da08ebd6400ff77d629c1eR309 chain() isn't mentioned here: http://wiki.ecmascript.org/doku.php?id=strawman:concurrency Promise.all() is included in the spec but not the case for serial execution: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.all-resolve-element-functions What seems like a preferred api / pattern from an ecma PoV to serially execute promises? e.g. Promise.serial(), Promise.ordered(), Promise.follow() Is it a common enough use case to be included in the spec? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Promise.cast and Promise.resolve
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Jonathan Bond-Caron jbo...@gdesolutions.com What seems like a preferred api / pattern from an ecma PoV to serially execute promises? Promise.prototype.then https://github.com/kriskowal/q#sequences ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On Fri, Feb 7, 2014 at 8:20 AM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: On Fri Feb 7 06:50 AM, Anne van Kesteren wrote: On Fri, Feb 7, 2014 at 12:45 PM, Yutaka Hirano yhir...@chromium.org wrote: Sorry for knowing little about ES consensus, is this the final decision? Will you change it again? Yeah, some clarity would be nice. From a user perspective, can someone explain what chain() does? .chain returns what is directly inside the promise, without doing any additional magic. This is different from .then, which flattens promises. For a more concrete example, assume that x is a PromisePromiseinteger. That is, it's a promise, holding a promise, holding an integer. x.chain(arg=arg is a PromiseInteger), x.then(arg=arg is an Integer). ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
The case for modular Loader.
The first goal listed for ecmascript modules:
- Obviate need for globals
(http://wiki.ecmascript.org/doku.php?id=harmony:modules).
Ironically, the current proposal for module loading includes a global
System and possibly Loader. Worse, it seems like the global System is
explicitly expected to be mutated.
Just in case the not-global is goal is controversial, consider the
following code snippets:
1. Using Globals:
System.import('./myGreatModule');
2. Using Modules:
import System from './MyCustomLoader';
System.import('./myGreatModule');
Which of these snippets provide a direct path to look for sources of error?
In the first one, you need to examine the entire program, and more over you
need to carefully consider whether order of execution may alter the
outcome. Any code that runs before the snippet, including code delayed by
network loading, can change the meaning of System. Such changes could make
perfect sense within one set of modules but become an error when those
modules are loaded in the same environment as another set.
By contrast, the second snippet directs your attention to a single file.
Let's look into what a custom loader module might look like:
import {SystemLoader, SystemLoaderHooks} from 'System'; // immutable
Loader class
class Loader extends SystemLoader {
constructor() {
super(SystemLoaderHooks);
}
// override, delegate, reuse SystemLoader API
// add non-standard custom functions
}
export var System = new Loader();
(Here I have used the capital variable System to emulate the module loader
discussion. Personally I think the package should be named 'system' and
developers should be using systemLoader.import().)
As a bonus, modular Loader would provide more incentive for developers to
adopt modules since they cannot use dynamic loading without also using
modules.
The only downside I see to a modular Loader is that simple demo code will
require two files. I hope someone will offer a stronger case for our
mutable global Loader.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
Kevin Smith wrote: If I may interject some opinions on process... Sure, it's es-discuss. Plus, you've earned your spurs. I'm not sure how this fits in with the new post-ES6 process, but from this one outsider's point of view: - A formal set of design goals should be completed and agreed upon before design work is begun. The design goals form the basis of measurement and the champion(s) must be bound to them at all times. Any changes to the design goal document must be carefully reviewed in order to prevent churn. A detailed change-log is an obvious requirement. Sounds both good in principle, and bad like waterfall. Waterfall is dead. Would such goals have helped promises? I bet we would have fought over the goals, at best. At worst, we'd agree to vague goals and end up where we ended up. - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. Yes, this. On a side note: it seems to me the the existence of the design champion, who by definition is deeply invested in the design process, implies the existence of its dual: the anti-champion, who is detached from the details of the design work and provides a vital holistic perspective. Yes, the _advocatus diaboli_. We have plenty of those, though. Too many, at this point. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntactic parameters
On Feb 5, 2014, at 9:30 PM, Michael Dyck wrote:
When I take the ECMAScript grammar and expand its abbreviations as outlined
in section 5.1.5, I get a grammar with lots of unreachable nonterminals
(i.e., symbols that can't appear in any sentential form derived from Script
or Module).
For instance, consider StrictFormalParameters. With its parameters Yield
and GeneratorParameter, it expands to 4 nonterminals:
StrictFormalParameters
StrictFormalParameters_Yield
StrictFormalParameters_GeneratorParameter
StrictFormalParameters_Yield_GeneratorParameter
(I use underscores to make the resulting names easier to read.)
I think I'll make the _ part of the expansion defined in chapter 5.
In the unexpanded grammar, it's used in only 3 productions:
14.2:
ArrowFormalParameters :
( StrictFormalParameters )
14.3:
MethodDefinition[Yield] :
PropertyName[?Yield] ( StrictFormalParameters ) { FunctionBody }
14.4:
GeneratorMethod[Yield] :
* PropertyName[?Yield]
( StrictFormalParameters[Yield,GeneratorParameter] )
{ FunctionBody[Yield] }
The first two of these expand to productions that reference
StrictFormalParameters
and the last one expands to productions that reference
StrictFormalParameters_Yield_GeneratorParameter.
So
StrictFormalParameters_Yield and
StrictFormalParameters_GeneratorParameter
are never referenced, and are thus unreachable.
Is this intentional? Or should StrictFormalParameters have a ?Yield
subscript in the 14.3 and 14.4 productions?
Yes, it's intentional.
The Yield parameter selects whether or not yield is treated as an identifier
or as an operator symbol. yield is only treated as an operator if the yield
parameter is present.
The GeneratorParameter parameter, when present, tags the use of a production
in the parameter list. A yield operation doesn't work as part of an
initializer or computed property name in a generator function's parameter list
because when parameter declarations are evaluated, the associated generator
object is not yet in a yield-able state. However, to avoid confusion, we want
to disallow the use of yield as an identifier throughout a generator
function including the parameter list. So, we parameterize
StrictFormalParameters for generator functions and methods with [Yield,
GeneratorParameter]. That parameter combination can be interpreted as don't
allow yield as an identifier but also don't allow it to be used as an
operator.
We never use StrictFormalParameter_Yield because that would permit the actual
use of the yield operator within a formal parameter initializer.
We never use [GeneratorParameter] by itself because that essentially means
allow yield as an identifier and don't treat it as an operator. That's
redundant.
I should probably make a statement in section 5 that not all expansions are
necessarily used.
14.3 is particularly interesting. consider:
don't use strict;
function *() {
return {
[yield something] (yield) {yield = 0}
}
}
Yield is validly treated a yield operator in determining the computed property
name but is a regular identifier in parameter list and body of the nest
function.
(And while we're in the
neighborhood, should FunctionBody also have a ?Yield subscript in those
productions?) If not, why not?
No, generator-ness and use of the yield operator doesn't propagate to nested
functions.
Similarly, I'm also wondering about the unreachability of
Statement_Yield
there is no statement context where yield is used as an operator but the return
statement is not allowed.
Declaration_Yield_Default
BindingIdentifier_Default_Yield
There is no context where default can be bound as an identifier and yield
can also be used as an operator.
Allen
-Michael
___
es-discuss 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
Re: Promise.cast and Promise.resolve
Le 07/02/2014 22:05, Brendan Eich a écrit : Kevin Smith wrote: - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. Yes, this. A working implementation is a lot of work, even a polyfill. But tests. Very recent case in point : https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 It was a lot of words in English, lots of HTML5 spec vocabulary with very special and detailed meaning, I had lost track at some point, even with the spec-y summary by Bobby [1]. But then, he created tests and that was suddenly fairly easy to review [2]. It was fairly easy to point places that might be under-spec'ed and needed more tests. Tests are an excellent medium to discuss feature design. The current test suite leaves room for interpretation on a corner case? throw in a new test to disambiguate! On a side note: it seems to me the the existence of the design champion, who by definition is deeply invested in the design process, implies the existence of its dual: the anti-champion, who is detached from the details of the design work and provides a vital holistic perspective. Yes, the _advocatus diaboli_. We have plenty of those, though. Too many, at this point. woopsy... David [1] https://etherpad.mozilla.org/html5-cross-origin-objects [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c133 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
David Bruant wrote: Le 07/02/2014 22:05, Brendan Eich a écrit : Kevin Smith wrote: - A *working* implementation should be created and solutions to real-world use cases should be programmed using the design before any spec language is authored. Spec-language is a poor medium for communicating both design intent and programming intent. Yes, this. A working implementation is a lot of work, even a polyfill. But tests. Very recent case in point : https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701 It was a lot of words in English, lots of HTML5 spec vocabulary with very special and detailed meaning, I had lost track at some point, even with the spec-y summary by Bobby [1]. But then, he created tests and that was suddenly fairly easy to review [2]. It was fairly easy to point places that might be under-spec'ed and needed more tests. Yeah, a warning to auto-didactic prose-heavy spec authors. Tests are an excellent medium to discuss feature design. The current test suite leaves room for interpretation on a corner case? throw in a new test to disambiguate! Tests++. Until they overspecify, then --. No silver bullets. More tests when in doubt. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a JavaScript
objects implemented class name. I have done this in the past with some
success by parsing the objects constructor but I know that this depends on
the Object constructor being named and is not very efficient as it requires
the processing of a large string.
Is it possible to include into the ECMA Specification a method of Object
that returns the constructor function name which can be subsequently be
used as an efficient class name detection mechanism? Maybe
Object.getFunctionName().
My current current slow but steady method for detecting classes is as
follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Efficient determination of implemented class name
o.constructor.name seems good?
From: Timothy Quinnmailto:tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a JavaScript
objects implemented class name. I have done this in the past with some success
by parsing the objects constructor but I know that this depends on the Object
constructor being named and is not very efficient as it requires the processing
of a large string.
Is it possible to include into the ECMA Specification a method of Object that
returns the constructor function name which can be subsequently be used as an
efficient class name detection mechanism? Maybe Object.getFunctionName().
My current current slow but steady method for detecting classes is as follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient determination of implemented class name
LOL. I did not realize that was implemented already :)
Thanks,
- Tim
On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
o.constructor.name seems good?
--
From: Timothy Quinn tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a
JavaScript objects implemented class name. I have done this in the past
with some success by parsing the objects constructor but I know that this
depends on the Object constructor being named and is not very efficient as
it requires the processing of a large string.
Is it possible to include into the ECMA Specification a method of Object
that returns the constructor function name which can be subsequently be
used as an efficient class name detection mechanism? Maybe
Object.getFunctionName().
My current current slow but steady method for detecting classes is as
follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient determination of implemented class name
Digging into ECMA-262, I cannot find this noted but it appears to be
implemented in V8 and SpiderMonkey.
Mozilla states this as
non-standardhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/nameso
I am guessing that its not documented in ECMA-262.
Is this defined in the specification or did I miss it? If not, +1 on its
standardization into the specification.
- Tim
On Fri, Feb 7, 2014 at 10:52 PM, Timothy Quinn tim.c.qu...@gmail.comwrote:
LOL. I did not realize that was implemented already :)
Thanks,
- Tim
On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
o.constructor.name seems good?
--
From: Timothy Quinn tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a
JavaScript objects implemented class name. I have done this in the past
with some success by parsing the objects constructor but I know that this
depends on the Object constructor being named and is not very efficient as
it requires the processing of a large string.
Is it possible to include into the ECMA Specification a method of Object
that returns the constructor function name which can be subsequently be
used as an efficient class name detection mechanism? Maybe
Object.getFunctionName().
My current current slow but steady method for detecting classes is as
follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient determination of implemented class name
Function name is in the latest ES6 draft.
On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com
wrote:
Digging into ECMA-262, I cannot find this noted but it appears to be
implemented in V8 and SpiderMonkey.
Mozilla states this as
non-standardhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/nameso
I am guessing that its not documented in ECMA-262.
Is this defined in the specification or did I miss it? If not, +1 on its
standardization into the specification.
- Tim
On Fri, Feb 7, 2014 at 10:52 PM, Timothy Quinn tim.c.qu...@gmail.comwrote:
LOL. I did not realize that was implemented already :)
Thanks,
- Tim
On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
o.constructor.name seems good?
--
From: Timothy Quinn tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a
JavaScript objects implemented class name. I have done this in the past
with some success by parsing the objects constructor but I know that this
depends on the Object constructor being named and is not very efficient as
it requires the processing of a large string.
Is it possible to include into the ECMA Specification a method of Object
that returns the constructor function name which can be subsequently be
used as an efficient class name detection mechanism? Maybe
Object.getFunctionName().
My current current slow but steady method for detecting classes is as
follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Efficient determination of implemented class name
Sweet. Thanks for the quick responses =D
On Fri, Feb 7, 2014 at 11:24 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
Function name is in the latest ES6 draft.
On Fri Feb 07 2014 at 11:15:31 PM, Timothy Quinn tim.c.qu...@gmail.com
wrote:
Digging into ECMA-262, I cannot find this noted but it appears to be
implemented in V8 and SpiderMonkey.
Mozilla states this as
non-standardhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/nameso
I am guessing that its not documented in ECMA-262.
Is this defined in the specification or did I miss it? If not, +1 on its
standardization into the specification.
- Tim
On Fri, Feb 7, 2014 at 10:52 PM, Timothy Quinn tim.c.qu...@gmail.comwrote:
LOL. I did not realize that was implemented already :)
Thanks,
- Tim
On Fri, Feb 7, 2014 at 10:28 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
o.constructor.name seems good?
--
From: Timothy Quinn tim.c.qu...@gmail.com
Sent: 2/7/2014 22:26
To: es-discuss@mozilla.org
Subject: Efficient determination of implemented class name
An area of challenge in JavaScript is the ability to detect a
JavaScript objects implemented class name. I have done this in the past
with some success by parsing the objects constructor but I know that this
depends on the Object constructor being named and is not very efficient as
it requires the processing of a large string.
Is it possible to include into the ECMA Specification a method of Object
that returns the constructor function name which can be subsequently be
used as an efficient class name detection mechanism? Maybe
Object.getFunctionName().
My current current slow but steady method for detecting classes is as
follows:
function objClassName(o){
if(o===undefined){return (undefined) }
if(o===null){return (null) }
var a=/function\s+(.+)\s*\(.*\)\s*\{/.exec(o.constructor)
return (a a[1] ? a[1] : (unknown))
};
Thanks!
Tim
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
