and input and outputs
will never differ base on any implicit, inferable, or backing types.
*Rules and constraint for writing a good scripting language or script for
that matter, such that it has consistent predictable and usable behaviour*
https://docs.google.com/document/d
Hi,
Just like to maybe challenge javascript here or any script language in that
mater.
The definition of comparing two variables with an operator such as
<.<=,>,>= of the operators above definition changes depending on the left
and right backing types.
If both are strings then it
On 07/06/2017 10:39 AM, Oriol _ wrote:
And why not just use
```js
const result = complexExpression();
const {a} = result;
let {b} = result;
```
and with arrays:
```js
const result = complexExpression();
const a = result[0];
let b = result[2];
```
That's exactly what I do now. It's
And why not just use
```js
const result = complexExpression();
const {a} = result;
let {b} = result;
```
and with arrays:
```js
const result = complexExpression();
const a = result[0];
let b = result[2];
```
If nothing else references `result`, it can be garbage-collected.
I don't see the
On 07/03/2017 12:25 PM, Jordan Harband wrote:
```
const { a } = o;
let { b } = o;
b = 1;
```
seems like a much simpler workaround than adding this complexity to
the language.
I dunno. I've wanted this numerous times. The use case is really
const { a, let b } = complexExpression();
A
```
const { a } = o;
let { b } = o;
b = 1;
```
seems like a much simpler workaround than adding this complexity to the
language.
Given your two examples, I'd find it bizarre for one to work and the other
not, so we'd want to support both. It also raises the question of
declaration-less
Totally minor, but
```
const {a, b} = o;
b = 1;
```
Complains that `b` is `const` and can't be assigned.
```
let {a, b} = o;
b = 1;
```
Now lint complains that `a` is never modified, and ought to be `const`.
So I would like to write:
```
const {a, let b} = o;
b = 1;
or alternatively
I haven't been able to find much talk on the value types proposal lately.
What's the status of it?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
At the last TC-39 meeting, the understanding I got was, it's OK to
bring SIMD to Stage 4 before value types are there as long as we have
a general understanding that value types are on track and will be
consistent with SIMD. I have been looking into value types, and I
believe they can be done
On Jan 6, 2015, at 2:25 PM, Isiah Meadows wrote:
Is there any restriction on what a tagged template can return in the spec?
Reading it (12.3.7.1) seems to imply not, but I'm not sure.
Nope, the returned value doesn't even need to be a string. that's sort of the
whole point...
Allen
Took a break while I worked on some Javascript projects for the past year to
see if they'd give me more perspective on types. I'll keep this short though.
Brendan Eich wrote:
No one is proposing type annotations a la ES4 or TypeScript, note well.
I'm thinking the discussion needs to start up
On Mon, Nov 24, 2014 at 9:00 AM, Brandon Andrews
warcraftthre...@sbcglobal.net wrote:
float32/64
- float16: common name: half, IEEE 754-2008: binary16, often used on GPUs
- float32: common name: float, IEEE 754-2008: binary32
- float64: common name: double, IEEE 754-2008: binary64
float16/80
decimal32/64/128
Those are reasonable additions also. Wasn't sure with decimal was going to
assume 128 bit for financial type applications. Having it vary with 32, 64, and
128 bit thought is much closer to the other suggestions. (I updated my original
post on esdiscuss to
Benjamin Gruenbaum wrote:
Correct, I mean value types (or objects) that have value semantics and support
operator overloading.
We'll probably talk about that tomorrow in a break-out. At least I hope to!
More after this week's TC39 meeting
We'll probably talk about that tomorrow in a break-out. At least I hope
to!
Thanks, this sounds awesome. It's definitely one of the most awaited ES7
features and it's definitely highly applicable in a lot of code I'm writing
(and in a lot I'm reading).
If there is any help you guys need with
Hey, I know ES7 value types are not yet done and are definitely not ready
for prime time but I'd really like to play with them to get a hang of the
API.
I'll be working on a library that will likely take a while to build and
will greatly benefit from them and I want to think about the API
Correct, I mean value types (or objects) that have value semantics and support
operator overloading.
On Nov 19, 2014, at 06:31, Katelyn Gadd k...@luminance.org wrote:
You don't mean typed objects, right? You mean value types, pass-by-value?
-kg
On 18 November 2014 02:36, Benjamin
Hello,
Isn't optional typing (similar to TypeScript) a good thing?
Let's say I want to do some image processing. And images can be really
huge nowadays. If I allocate an array of dynamic variables, that array
may be 10x larger than if it was an array of bytes. And I need bytes to
store and
Use typed arrays.
From: Zexxmailto:zex2...@gmail.com
Sent: 2014-10-30 20:16
To: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
Subject: Types
Hello,
Isn't optional typing (similar to TypeScript) a good thing?
Let's say I want to do some image processing
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects
On Oct 30, 2014, at 9:27 PM, Domenic Denicola d...@domenic.me wrote:
Use typed arrays.
___
es-discuss mailing list
es-discuss@mozilla.org
TypeScript is about static type checking (and IDE support), what you want
dynamic types that are better fits for problem domains. This is a step in that
direction (in addition to typed arrays in ES6):
https://github.com/dslomov-chromium/typed-objects-es7
https://github.com/dslomov-chromium
. This
use of spec-internal reference-semantics mutable record could be awkward in
a future edition:
https://github.com/sebmarkbage/ecmascript-immutable-data-structures
But that is describing language level types, not spec. devices. they would not
directly map to the List/Record specification
-internal device a
record. This use of spec-internal reference-semantics mutable
record could be awkward in a future edition:
https://github.com/sebmarkbage/ecmascript-immutable-data-structures
But that is describing language level types, not spec. devices. they
would not directly map to the List
point.
Some might object to calling any such spec-internal device a record. This
use of spec-internal reference-semantics mutable record could be awkward
in a future edition:
https://github.com/sebmarkbage/ecmascript-immutable-data-structures
But that is describing language level types
Allen Wirfs-Brock wrote:
Naming and other such editorial conventions can evolve, but in terms of
finishing ES6 they are lower priority than resolve remaining bugs and open
technical issues.
Easiest fix: s/\Record\/Struct/g or better. Just a thought, not
putting this on your plate, rather
It's not obvious to me from
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-list-and-record-specification-type
whether a Record is a value type or reference type.
At least some parts of the spec seem to assume it's a reference type.
Specifically,
On 10/26/14, 11:12 PM, Allen Wirfs-Brock wrote:
ES List and Record specification type values have reference semantics
OK. Can we explicitly say so in the spec, please?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
record could be
awkward in a future edition:
https://github.com/sebmarkbage/ecmascript-immutable-data-structures
Does the spec anywhere else need reference semantics for its internal
list and record types?
/be
___
es-discuss mailing list
es-discuss
Alex Vincent wrote:
var x = new SmallDecimal(2);
var y = new SmallDecimal(3);
[x y, x y, x == y, x = y, x = y, x != y]
valueOf doesn't work for SmallDecimal(2) == SmallDecimal(2), though. You
have to hash-cons, which kils performance.
String relational order is wrong for numeric types
I like the idea of value types, but I wonder if, for terminating decimal
numbers, the .valueOf() method from Object.prototype might be sufficient
for many operations.
Example:
function SmallDecimal(k) {
this.__value__ = k;
}
SmallDecimal.prototype.valueOf = function() {
return
. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/
typed-objects-status-report/
and the second details some (preliminary) thoughts on how one could
build on typed objects to support user-defined value types:
http://smallcultfollowing.com/babysteps/blog
Note that value object proposal does not address int64.
FWIW, I'm too interested in solving the int64 problem somehow. The last I
heard about int64 was here:
http://www.slideshare.net/BrendanEich/value-objects2. How does the int64
story move forward?
--
Cristian Petrescu-Prahova | Software
int64 and uint64 are integral parts of value objects, first proofs of
concept even. Sorry I fell behind on the SpiderMonkey bug, I'm hoping
others will take it over (cc'ed; and for V8) and revive it. It has
obvious use-cases in Node.js and anything that tiles the OS syscall surface.
/be
details some (preliminary) thoughts on how one could
build on typed objects to support user-defined value types:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/value-types-in-javascript/
We've been tossing things like this around for a while. I'd personally love to
have some notion
I guess the analog for this in traditional JS 'Object' instances is
that when you use the [] operator, i.e. obj[valueObject], it actually
does obj[valueObject.toString()], so you can control the 'hashing
function' in a sense by overriding toString. It seems natural to want
something equivalent
On Sunday, April 6, 2014, K. Gadd k...@luminance.org wrote:
I guess the analog for this in traditional JS 'Object' instances is
that when you use the [] operator, i.e. obj[valueObject], it actually
does obj[valueObject.toString()], so you can control the 'hashing
function' in a sense by
An there is nothing stopping someone from defining their own map class
(possibly by subclassing Map) that has its own hashing and comparison policies.
JS implementations + ES6 functionality are good enough that we don't have to
wait for such things to be built-in.
Allen
On Apr 6, 2014, at
I'd like to raise an issue with ES7 value objects with maps raised here:
http://esdiscuss.org/topic/maps-with-object-keys
To save you all time, let me sum things up:
ES6 maps don't solve a particular (but common) issue for me - using
compound objects as keys. I do a lot of statistical analysis
Given that Color is a struct type object, is there a more direct way of
getting the common prototype of all the array type objects with different
dimensions with this element type, than by calling
getPrototypeOf(Color.arrayType.prototype)?
___
es-discuss
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
speaks of typed objects comparing structurally. Typed objects have identity,
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.comwrote:
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
On 3 April 2014 09:00, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
On 2 April 2014 20:26, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The
current
discussion
On Thu, Apr 3, 2014 at 9:40 AM, Andreas Rossberg rossb...@google.comwrote:
You'd have to unwrap the whole fat pointer, right?
Yes, of course. I simplified a bit.
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, Apr 3, 2014 at 3:00 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
A uvalue is deeply uvalue only when its prototype and all the methods
found
there are uvalues. Although this is the case for E, the
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
You can never compare uvalues from different realms: both uvalues need
to be in the same realm before you can do the comparison. All you
need is that equal uvalues in realm A become equal uvalues in realm B
when passed over.
Le 3 avr. 2014 à 07:33, Andreas Rossberg rossb...@google.com a écrit :
Not sure what type 'object' is used for in the wild.
I sometimes use it for distinguishing between Object-like objects and
primitive values (usually together with an additional test for excluding
`null`).
For that
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg rossb...@google.comwrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
to be the same everywhere, and because the language can hence apply
some
hands here, but it seems to me that a two-part solution
could work:
1) by default, objects passed between realms retain their original
uvalue type id (realm id + id of uvalue in that realm) but become
new anonymous uvalue types with no prototype (although field names and
types are preserved
On 3 April 2014 15:30, Marius Gundersen gunder...@gmail.com wrote:
On Thu, Apr 3, 2014 at 3:09 PM, Andreas Rossberg rossb...@google.com
wrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
to be the
On 3 April 2014 15:39, C. Scott Ananian ecmascr...@cscott.net wrote:
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg rossb...@google.com wrote:
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
Unfortunately, that only works for primitives because the respective
could
build on typed objects to support user-defined value types:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/value-types-in-javascript/
Niko
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
/
and the second details some (preliminary) thoughts on how one could
build on typed objects to support user-defined value types:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/value-types-in-javascript/
That is very helpful, thanks! I agree with a lot with what you say.
But to expand
On Wed, Apr 2, 2014 at 5:01 PM, Andreas Rossberg rossb...@google.comwrote:
Other properties, like the ability to use an object as keys in weak
collections, follow from that. If we suddenly allowed objects that do
not have identity, but a structural notion of equality, then we could
not allow
-status-report/
and the second details some (preliminary) thoughts on how one could
build on typed objects to support user-defined value types:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/value-types-in-javascript/
Just a quick local editorial comment for now:
...
points[0].x = 1
I really appreciate you guys making === (not just ==) work for value types. I
think that drastically improves the usability compared to earlier proposals.
I can see Andreas's concerns regarding what that means for their object-ness
though. But hopefully that can be worked out while still
concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
and the second details some (preliminary) thoughts on how one could
build on typed objects to support user-defined value types:
http
Commenting on this same region:
```
print(points[0].x); // 0 to start
points[0].x = 1;
print(points[0].x); // still 0
points[0] = {x: 1, y: 2};
print(points[0].x); // now 1
```
There's no reason why we couldn't extend the grammar to handle this
case, in the same way that `a.f()` has different
doubting about it
2. no idea why types shouldn't be initialized either with or without
`new`, which is the most natural way to write objects in JS since kinda
ever (new Point() VS Point() ... how about it's just the same as it is for
new Object() VS Object() ... if String comes out
I think the idea that value types should be objects would
require stretching the notion of object too far, and violate one of
the fundamental properties that objects currently have.
Certainly this was the idea, though I didn't think of it is as
violating, but rather... stretching. :)
Other
On 4/2/2014 8:01 AM, Andreas Rossberg wrote:
That is very helpful, thanks! I agree with a lot with what you say.
But to expand on my reply to your blog post, I have one fundamental
concern: I think the idea that value types should be objects would
require stretching the notion of object too far
On Wed, Apr 2, 2014 at 10:37 AM, Niko Matsakis n...@alum.mit.edu wrote:
I think the idea that value types should be objects would
require stretching the notion of object too far, and violate one of
the fundamental properties that objects currently have.
Certainly this was the idea, though
On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation when it
speaks of typed objects comparing structurally. Typed objects have
On Wed, Apr 2, 2014 at 9:11 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Wed, Apr 2, 2014 at 8:26 PM, Mark S. Miller erig...@google.com wrote:
We could specify that WeakMaps can use typed objects as keys. The current
discussion in your article confuses semantics with implementation
On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller erig...@google.com wrote:
You can't recreate a given fat pointer out of thin air. You need at least
the same backing buffer, or something (e.g., another fat pointer) which
retains the same backing buffer.
The backing buffer has generative
On Wed, Apr 2, 2014 at 1:02 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Wed, Apr 2, 2014 at 9:36 PM, Mark S. Miller erig...@google.com wrote:
You can't recreate a given fat pointer out of thin air. You need at least
the same backing buffer, or something (e.g., another fat pointer) which
On Wed, Apr 2, 2014 at 10:17 PM, Mark S. Miller erig...@google.com wrote:
However, I have to quibble with observable. WeakRefs make GC observable.
WeakMaps do not. Running out of memory, or failing to, is not an
observation, since the spec never says when this might or might not occur
What missing expressive capability does this give developers, aside from
overloading of equality?
Obviously, being able to directly represent an int33 (for example) is
useful, but I'm not seeing the motivation behind user-defined value
objects, yet, aside from overloading equality.
On Wed, Apr
of which should be obvious. It
also has user-definable numeric suffixes, for simple types of
uvalues whose constructor can take a single numeric value. This lets
CSS, for example, define a set of uvalues for all of its dimensions,
so authors can write `element.css.width += 50px;` rather than
feature.
However, there are certain invariants that people seem to rely on
regarding typeof, e.g. that testing for type 'function' identifies
callables, Not sure what type 'object' is used for in the wild.
I also remember one TC39 discussion from 1+ year ago where we
concluded that new future types
the nature of
the beast with mutable reference types. Pretty much all JS matrix libraries
today use:
if (mutMatA.equals(mutMatB)) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
which I assume would suffer from the same bug?
It's true that in JS today, comparing
Tristan Zajonc wrote:
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
Is this bug related to operator overloading? It seems just the nature
of the beast with mutable reference types. Pretty much all JS matrix
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with declarative syntax to
solve several problems:
1. Backward compatibility,
the nature of
the beast with mutable reference types. Pretty much all JS matrix libraries
today use:
if (mutMatA.equals(mutMatB)) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
which I assume would suffer from the same bug?
You bet, but special forms exist
On Tue, Oct 29, 2013 at 10:08 AM, Brendan Eich bren...@mozilla.com wrote:
Tristan Zajonc wrote:
It's true that in JS today, comparing an object to a non-object,
valueOf or toString on the object can be used to make == results vary.
However, I'm proposing value objects with
One clarification on the value objects proposal... The JSConf slides say
that immutability is implemented as an implicit Object.freeze(this) on
return in the constructor. Is this meant as shorthand for a deep freeze?
On Tue, Oct 29, 2013 at 11:13 AM, Tristan Zajonc
Tristan Zajonc wrote:
One clarification on the value objects proposal... The JSConf slides
say that immutability is implemented as an implicit
Object.freeze(this) on return in the constructor. Is this meant as
shorthand for a deep freeze?
Yes, although depth may be hard to generalize. A
Tristan Zajonc mailto:tris...@senseplatform.com
October 27, 2013 5:47 PM
I apologize for jumping in here with an incomplete understanding
what's being proposed, but perhaps somebody can help clarify it for
me. I've been following value types and operator overloading
discussion with great
Brendan Eich wrote:
The API Function.defineOperator(symbol, type1, type2) would be
perfect to support this. However I assume this is not the intention?
Is there any openness to supporting user defined infix operators or
at least an extended set similar to Python's PEP 225 proposal
clarify it for me. I've been
following value types and operator overloading discussion with great
interest. From the slides and video, it appears that operator overloading
is only being discussed in the context of immutable value objects. Is this
right? Or is it just what the examples use
Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS
requirement. For a matrix API, there is some flexibility on
comparison operators, but transient value comparison returning a
single boolean is the most natural, other issues aside. I'm not sure I
fully
On Sun, 10/27/13, Domenic Denicola dome...@domenicdenicola.com wrote:
Subject: RE: Proposal for new floating point and integer data types
To: Rick Waldron waldron.r...@gmail.com, Brandon Andrews
warcraftthre...@sbcglobal.net
Cc: es-discuss
Brandon Andrews mailto:warcraftthre...@sbcglobal.net
October 27, 2013 5:45 AM
On Sun, 10/27/13, Domenic Denicola dome...@domenicdenicola.com wrote:
Subject: RE: Proposal for new floating point and integer data types
To: Rick Waldron waldron.r
Brendan Eich wrote:
Here's what Alon wrote recently:
Alon Zakai, creator of Emscripten, first among discoverers of asm.js.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I apologize for jumping in here with an incomplete understanding what's
being proposed, but perhaps somebody can help clarify it for me. I've been
following value types and operator overloading discussion with great
interest. From the slides and video, it appears that operator overloading
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I think since the process
takes a while it would be a good idea to consider adding extra data types on
top of the already existing dynamic ones. I'll keep each comment short
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I
@mozilla.org
Subject: Re: Proposal for new floating point and integer data types
Sorry for the top post, but I recommend reading this:
http://wiki.ecmascript.org/doku.php?id=strawman:value_types
Rick
On Saturday, October 26, 2013, Brandon Andrews wrote:
I've seen posts asking for optional strong
Agreed, I'll remove them from the polyfill.
On Wed, Aug 21, 2013 at 10:34 PM, David Herman dher...@mozilla.com wrote:
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote:
I really hope that uint64 from value type spec and uint64 from typed
object spec are one and same
moving back onto list
It might be worth doing. On the one hand, I don't really feel like these
names *should* collide with anything, but it seems like the risk is kinda
high... and it's a little weird seeing them in global scope and having to
figure out that they're actually types for binary data
time), a
namespace would work and look way better.
B as Binary Object or b, as binary namespace or even binary would be OK
**but** this stuff has been renamed already into Typed Object so binary
should be left aside ..
T as entry point for Types ... I lie it but I am sure somebody will laugh
about
renamed already into Typed Object so binary
should be left aside ..
T as entry point for Types ... I lie it but I am sure somebody will laugh
about a single char namespace, even if T is used everywhere to describe
Types indeed in all other programming languages ...
typed would be meaningful too
with anything, but it seems like the risk is kinda
high... and it's a little weird seeing them in global scope and having to
figure out that they're actually types for binary data and not, for example,
the constructor for boolean or some sort of value type ctor.
Once 64-bit signed/unsigned ints
like the risk is kinda
high... and it's a little weird seeing them in global scope and having to
figure out that they're actually types for binary data and not, for example,
the constructor for boolean or some sort of value type ctor.
Once 64-bit signed/unsigned ints are in will there be two
is T as single top level object an option?
is any of these an option: typed, types, type, or TypedObject ?
if not, which one would be ?
On Wed, Aug 21, 2013 at 12:09 PM, David Herman dher...@mozilla.com wrote:
If necessary, i.e. if people want to release it before modules, we can
make
scope and having to
figure out that they're actually types for binary data and not, for
example, the constructor for boolean or some sort of value type ctor.
Once 64-bit signed/unsigned ints are in will there be two names for those
as well? I.e. Uint64(...) produces one of the new 64-bit unsigned
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote:
I really hope that uint64 from value type spec and uint64 from typed object
spec are one and same thing (we now in typed objects spec allow using
uint8/uint16/.. co to be used as conversion functions).
Agreed, and my
Hi,
My apologies if that's being already discussed (have not being following this
list actively lately).
I would be really love if error types could be standardised such that
`fileName`, `lineNumber` information could be taken from them reliably.
It would be also great if error.stack
On Thursday, February 28, 2013, Irakli Gozalishvili wrote:
Hi,
My apologies if that's being already discussed (have not
being following this list actively lately).
I would be really love if error types could be standardised such that
`fileName`, `lineNumber` information could be taken from
Tab Atkins Jr. wrote:
let o = { items: function() {} };
would pass that test.
I'm not sure how else you're supposed to detect iterables.
It's not 'items', btw. The iterator-getter/maker is named 'iterator' in
SpiderMonkey currently, and last I heard would be @iterator (well-known
public
)),
but not invoking the Map constructor and actually storing data in a
closure-hidden internal Map, so instanceof would work but using Map's
own methods wouldn't.
Or, we could ignore the whole thing, and just make sure that we
ducktype as a Map.
That's some pretty weak sauce. Lining up the types
1 - 100 of 185 matches
Mail list logo
