Re: Feature Request

[Isiah Meadows]

I've weakly suggested this in the past (sorry, buried in old list
discussions and IRC), but I haven't come up with something that 1.
doesn't have nearly the overhead of web workers, and 2. doesn't have
nearly the footguns of C's direct thread-based model that's mostly
emulated by practically every remotely major software programming
language not using CSP or actors/processes. The first is difficult to
avoid without avoiding message passing altogether, hence why
`SharedArrayBuffer` appeared in the first place. The second is
difficult to avoid if you want to minimize message passing overhead,
especially without immutable objects (which can usually be sent
without copy between threads of the same parent process).

Given Erlang's parallel programming model has proven itself to stand
the test of time (it's hardly changed since the 80s) and that others
(such as Ruby and some Java circles) are planning to adapt it, I feel
it might be worth waiting for this stage-0 proposal to make it in in
some form or another first, *then* pushing for language-level support
of parallelism: https://github.com/rricard/proposal-const-value-types/

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com

-

Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com


On Tue, Jun 25, 2019 at 9:51 AM Robert Parham  wrote:
>
>
> Are there any threading proposals? If not, would anyone be interested in 
> creating one?
>
> Webworkers are great, but require separate files that just aren't always 
> convenient to maintain. I've
> created this wrapper for webworkers that allows users to create in-line 
> disposable threads, somewhat
> similar to threads in Java.
>
> https://gist.github.com/Pamblam/683d5ae429448adfa6d6e7fb30de39b2
>
> If we could get something similar implemented natively that would be very 
> cool.
>
> Robert "Gordie" Parham
> pamblam.com
> 813.616.0819
>
>
>
>
> ___
> 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: [Feature Request] Built-in `deepCopy/deepClone` (based on the structured cloning algorithm)

[Jordan Harband]

You may be interested to read some previous discussions around this topic:
 - https://esdiscuss.org/topic/structured-clones
 - https://esdiscuss.org/topic/the-structured-clone-wars
 - https://esdiscuss.org/topic/object-clone-not-quite-a-proposal
 - https://esdiscuss.org/topic/object-equals-and-object-clone

On Fri, Dec 7, 2018 at 6:00 AM Harry Manchanda 
wrote:

> Heya, I tried before to write this but seems like I wasn't subscribed. Now
> seems like I subscribed so posting it again...
>
> So here we go,
>
> I am posting this after an aftermath of a Github Issue. See =>
> https://github.com/tc39/proposals/issues/150
>
> I would like the JavaScript (ECMAScript) Spec to include built-in
> `deepCopy/deepClone` feature.
>
> Please note that based on the response at Github Issue and also
> considering that the top 3 npm packages for cloning have over 100k weekly
> downloads I am very positive on this and should be really considered.
>
> I think we have two approaches to consider for same
>
> 1. Object Oriented approach
>
> ```js
> // Object.prototype.deepCopy(), Array.prototype.deepCopy(), etc
>
> const harry = {
>   name: 'Harry Manchanda',
>   age: 25,
>   social: [
> {
>   website: 'twitter',
>   username: '@harmanmanchanda',
> },
> {
>   website: 'facebook',
>   username: 'IamManchanda',
> },
>   ],
> };
>
> const dev = harry.deepCopy();
> dev.social[1].website = 'github';
> ```
>
> 2. Functional Programming approach
>
> ```js
> // Object.deepCopy(value)
> // Value expects array, objects and primitives
>
> const harry = {
>   name: 'Harry Manchanda',
>   age: 25,
>   social: [
> {
>   website: 'twitter',
>   username: '@harmanmanchanda',
> },
> {
>   website: 'facebook',
>   username: 'IamManchanda',
> },
>   ],
> };
>
> const dev = Object.deepCopy(harry);
> dev.social[1].website = 'github';
> ```
>
>
> Reason why I think so strongly that everyone in javascript community needs
> this is this
>
> => https://gist.github.com/search?l=JavaScript=deepcopy
> => https://gist.github.com/search?l=JavaScript=deepclone
> => https://github.com/search?l=JavaScript=deepcopy=Repositories
> => https://github.com/search?l=JavaScript=deepclone=Repositories
>
>
> *Thanks,*
>
> *Harman Singh Manchanda ( Harry )*
> *Open Source Team Member - Zurb Foundation
> *
> ___
> 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: Feature request: Array.prototype.random

[Michael J. Ryan]

Just putting in my $.02

I'm thinking math-rnd-util as an npm module would be a place to start...
Then propose extending Math.rnd = rnd-util

Rnd.fill(array)
Rnd.pick(array)
Rnd.pick(min:int, max:int)
...

I suggest flushing things out in a usable npm module would be a good start.

-- 
Michael J. Ryan - track...@gmail.com - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my
phone.

On Jun 20, 2017 3:20 AM, "Henrik Sommerland" 
wrote:

> I agree that having a random integer function would be more suitable.
> Picking a random element from an array is a fairly uncommon thing but
> generating a random integer in a given range is something much more
> desirable.
>
> 2017-06-20 11:33 GMT+02:00 Isiah Meadows :
>
>> Better idea: let's introduce an integer-based `Math.random` equivalent
>> that can be optionally constrained to a specific range.
>>
>>
>> ```js
>> // Simple polyfill
>> Math.randomInt = Math.randomInt || function (start, end) {
>> if (arguments.length === 0) {
>> start = 0; end = Number.MAX_SAFE_INTEGER
>> } else if (arguments.length === 1) {
>> end = start; start = 0
>> }
>> start = Math.max(Math.floor(start), -Number.MAX_SAFE_INTEGER)
>> end = Math.min(Math.floor(end), Number.MAX_SAFE_INTEGER)
>>
>> return Math.floor(Math.random() * (end - start)) + start
>> }
>> ```
>>
>> You could then use it like this:
>> `array[Math.randomInt(array.length)]`. I feel in this particular case,
>> a more general solution is much more useful than just a "pick some
>> random item in an array". (Number guessing games, anyone?)
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>>
>> On Thu, Jun 15, 2017 at 6:20 PM, William White 
>> wrote:
>> > And prng.pick(str), prng.pick(set) etc.?
>> >
>> > On 15 Jun 2017, at 22:34, Michał Wadas  wrote:
>> >
>> > I believe it's too specialized to be a part of Array interface.
>> >
>> > Though, I think JS should have better support for randomness, so we
>> could
>> > do:
>> >
>> > prng.pick(arr);
>> > prng.sample(arr, 5);
>> > prng.sampleWithoutRepetitions(arr, 4);
>> >
>> > On 15 Jun 2017 20:42, "Will White"  wrote:
>> >
>> > Dear es-discuss,
>> >
>> > I would like to propose Array.prototype.random, which would return a
>> random
>> > array element the same way `array[Math.floor(Math.random() *
>> array.length)]`
>> > does, because every time I want a random array element, I have to
>> remember
>> > how to do it. Do you think this is a useful addition to the language?
>> >
>> > Will White
>> > ___
>> > 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
>> >
>> ___
>> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature request: Array.prototype.random

[Henrik Sommerland]

I agree that having a random integer function would be more suitable.
Picking a random element from an array is a fairly uncommon thing but
generating a random integer in a given range is something much more
desirable.

2017-06-20 11:33 GMT+02:00 Isiah Meadows :

> Better idea: let's introduce an integer-based `Math.random` equivalent
> that can be optionally constrained to a specific range.
>
>
> ```js
> // Simple polyfill
> Math.randomInt = Math.randomInt || function (start, end) {
> if (arguments.length === 0) {
> start = 0; end = Number.MAX_SAFE_INTEGER
> } else if (arguments.length === 1) {
> end = start; start = 0
> }
> start = Math.max(Math.floor(start), -Number.MAX_SAFE_INTEGER)
> end = Math.min(Math.floor(end), Number.MAX_SAFE_INTEGER)
>
> return Math.floor(Math.random() * (end - start)) + start
> }
> ```
>
> You could then use it like this:
> `array[Math.randomInt(array.length)]`. I feel in this particular case,
> a more general solution is much more useful than just a "pick some
> random item in an array". (Number guessing games, anyone?)
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Thu, Jun 15, 2017 at 6:20 PM, William White 
> wrote:
> > And prng.pick(str), prng.pick(set) etc.?
> >
> > On 15 Jun 2017, at 22:34, Michał Wadas  wrote:
> >
> > I believe it's too specialized to be a part of Array interface.
> >
> > Though, I think JS should have better support for randomness, so we could
> > do:
> >
> > prng.pick(arr);
> > prng.sample(arr, 5);
> > prng.sampleWithoutRepetitions(arr, 4);
> >
> > On 15 Jun 2017 20:42, "Will White"  wrote:
> >
> > Dear es-discuss,
> >
> > I would like to propose Array.prototype.random, which would return a
> random
> > array element the same way `array[Math.floor(Math.random() *
> array.length)]`
> > does, because every time I want a random array element, I have to
> remember
> > how to do it. Do you think this is a useful addition to the language?
> >
> > Will White
> > ___
> > 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
> >
> ___
> 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: Feature request: Array.prototype.random

[peter miller]

Isaiah,


Better idea: let's introduce an integer-based `Math.random` equivalent
that can be optionally constrained to a specific range.



There's a discussion of it here:

https://github.com/rwaldron/proposal-math-extensions/issues/8

Peter

--
"There were drawings, and sheets of paper with writing on them, and it  
seemed that they were the sustenance of life, that here were the warlocks,  
almost the vehicles of destruction of man's life, but at the same time the  
very reason for his living." --- Maeve Gilmore/Titus Awakes.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature request: Array.prototype.random

[Isiah Meadows]

Better idea: let's introduce an integer-based `Math.random` equivalent
that can be optionally constrained to a specific range.


```js
// Simple polyfill
Math.randomInt = Math.randomInt || function (start, end) {
if (arguments.length === 0) {
start = 0; end = Number.MAX_SAFE_INTEGER
} else if (arguments.length === 1) {
end = start; start = 0
}
start = Math.max(Math.floor(start), -Number.MAX_SAFE_INTEGER)
end = Math.min(Math.floor(end), Number.MAX_SAFE_INTEGER)

return Math.floor(Math.random() * (end - start)) + start
}
```

You could then use it like this:
`array[Math.randomInt(array.length)]`. I feel in this particular case,
a more general solution is much more useful than just a "pick some
random item in an array". (Number guessing games, anyone?)
-

Isiah Meadows
m...@isiahmeadows.com


On Thu, Jun 15, 2017 at 6:20 PM, William White  wrote:
> And prng.pick(str), prng.pick(set) etc.?
>
> On 15 Jun 2017, at 22:34, Michał Wadas  wrote:
>
> I believe it's too specialized to be a part of Array interface.
>
> Though, I think JS should have better support for randomness, so we could
> do:
>
> prng.pick(arr);
> prng.sample(arr, 5);
> prng.sampleWithoutRepetitions(arr, 4);
>
> On 15 Jun 2017 20:42, "Will White"  wrote:
>
> Dear es-discuss,
>
> I would like to propose Array.prototype.random, which would return a random
> array element the same way `array[Math.floor(Math.random() * array.length)]`
> does, because every time I want a random array element, I have to remember
> how to do it. Do you think this is a useful addition to the language?
>
> Will White
> ___
> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature request: Array.prototype.random

[William White]

And prng.pick(str), prng.pick(set) etc.?

> On 15 Jun 2017, at 22:34, Michał Wadas  wrote:
> 
> I believe it's too specialized to be a part of Array interface. 
> 
> Though, I think JS should have better support for randomness, so we could do:
> 
> prng.pick(arr);
> prng.sample(arr, 5);
> prng.sampleWithoutRepetitions(arr, 4);
> 
> On 15 Jun 2017 20:42, "Will White"  wrote:
> Dear es-discuss,
> 
> I would like to propose Array.prototype.random, which would return a random 
> array element the same way `array[Math.floor(Math.random() * array.length)]` 
> does, because every time I want a random array element, I have to remember 
> how to do it. Do you think this is a useful addition to the language?
> 
> Will White
> ___
> 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: Feature request: Array.prototype.random

[Michał Wadas]

I believe it's too specialized to be a part of Array interface.

Though, I think JS should have better support for randomness, so we could
do:

prng.pick(arr);
prng.sample(arr, 5);
prng.sampleWithoutRepetitions(arr, 4);

On 15 Jun 2017 20:42, "Will White"  wrote:

Dear es-discuss,

I would like to propose Array.prototype.random, which would return a random
array element the same way `array[Math.floor(Math.random() *
array.length)]` does, because every time I want a random array element, I
have to remember how to do it. Do you think this is a useful addition to
the language?

Will White
___
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: Feature Request: Make ECMA262 a superset of JSON

[Isiah Meadows]

Inline.

On Tue, Oct 18, 2016, 12:01 Richard Gibson  wrote:

> On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows 
> wrote:
>
> I'll point out that encoding and evaluating JSON literally can easily
> become a potential security issue, anyways (consider if a user can encode
> `-->` in the relevant data). But you might have a point if you
> consider JSONP.
>
>
> This feels like it's drifting a bit. I'm asserting that the "the
> alternative definition of *DoubleStringCharacter*" required for
> JSON.parse can in fact become the *only* definition of that production,
> retroactively validating the currently-false claims in §24.3.1
>  of JSON being a subset
> of ECMAScript literals. U+2028 and U+2028 would still be line terminators
> for purposes of ASI/line numbering/etc., but would be allowed unescaped in
> string literals.
>

I'll also mention that the JSON website does claim to be "based on" a
subset (the JavaScript object literal syntax), but there is a subtle
distinction.

I'll admit my original statement was probably not fully on topic, though (I
was uncertain whether I should've said it or not).


> On Sun, Oct 16, 2016, 22:08 Richard Gibson 
> wrote:
>
> Allow me to clarify: permitting U+2028 and U+2029 in ECMAScript strings
> would allow safely embedding arbitrary JSON in the precise sense that such
> embeddings would always be syntactically valid and evaluatable Literal,
> ArrayLiteral, or ObjectLiteral expressions. That is already true of
> "__proto__" keys, even though their evaluation results in web browsers
> don't exactly match JSON.parse.
>
>
> By the way, `"__proto__"` is intentionally different than `__proto__` to
> avoid a gaping security hole for those using objects as dictionaries
> (untrusted code causing prototypes to change is bad). The string version is
> no different from any other property, while the identifier version either
> gets or sets the prototype.
>
>
> While irrelevant to the proposed change, that appears to be false (though
> it would certainly be beneficial if true)—the special check for "__proto__"
> in Step 5 of §B.3.1
> 
>  uses
> *propKey*, which step 1 defines as "the result of evaluating
> *PropertyName*", and evaluation of *LiteralPropertyName* in §12.2.6.7
> 
>  does
> not preserve a distinction between *IdentifierName* and *StringLiteral*
> forms in its result. I also observe equal treatment of quoted and unquoted
> "__proto__" object literal properties in SpiderMonkey, V8, and Chakra.
>

I tested it myself earlier, and took back my initial statement in another
email, since I think someone else beat you to it (it's computed vs not).

>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Request: Make ECMA262 a superset of JSON

[Richard Gibson]

On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows 
wrote:

> I'll point out that encoding and evaluating JSON literally can easily
> become a potential security issue, anyways (consider if a user can encode
> `-->` in the relevant data). But you might have a point if you
> consider JSONP.
>

This feels like it's drifting a bit. I'm asserting that the "the
alternative definition of *DoubleStringCharacter*" required for JSON.parse
can in fact become the *only* definition of that production, retroactively
validating the currently-false claims in §24.3.1
 of JSON being a subset of
ECMAScript literals. U+2028 and U+2028 would still be line terminators for
purposes of ASI/line numbering/etc., but would be allowed unescaped in
string literals.

On Sun, Oct 16, 2016, 22:08 Richard Gibson  wrote:
>
>> Allow me to clarify: permitting U+2028 and U+2029 in ECMAScript strings
>> would allow safely embedding arbitrary JSON in the precise sense that such
>> embeddings would always be syntactically valid and evaluatable Literal,
>> ArrayLiteral, or ObjectLiteral expressions. That is already true of
>> "__proto__" keys, even though their evaluation results in web browsers
>> don't exactly match JSON.parse.
>>
>
> By the way, `"__proto__"` is intentionally different than `__proto__` to
> avoid a gaping security hole for those using objects as dictionaries
> (untrusted code causing prototypes to change is bad). The string version is
> no different from any other property, while the identifier version either
> gets or sets the prototype.
>

While irrelevant to the proposed change, that appears to be false (though
it would certainly be beneficial if true)—the special check for "__proto__"
in Step 5 of §B.3.1

uses
*propKey*, which step 1 defines as "the result of evaluating *PropertyName*",
and evaluation of *LiteralPropertyName* in §12.2.6.7

does
not preserve a distinction between *IdentifierName* and *StringLiteral*
forms in its result. I also observe equal treatment of quoted and unquoted
"__proto__" object literal properties in SpiderMonkey, V8, and Chakra.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Request: Make ECMA262 a superset of JSON

[Isiah Meadows]

Okay. I stand corrected (it was in fact `["__proto__"]` that actually
evaluates to the property).

-

Isiah Meadows
m...@isiahmeadows.com

On Tue, Oct 18, 2016 at 9:58 AM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:

> Note that `["__proto__"]` is different from `__proto__`, while
> `"__proto__"` is the same as `__proto__`.
>
> ___
> 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: Feature Request: Make ECMA262 a superset of JSON

[Richard Gibson]

Allow me to clarify: permitting U+2028 and U+2029 in ECMAScript strings
would allow safely embedding arbitrary JSON in the precise sense that such
embeddings would always be syntactically valid and evaluatable Literal,
ArrayLiteral, or ObjectLiteral expressions. That is already true of
"__proto__" keys, even though their evaluation results in web browsers
don't exactly match JSON.parse.

On Fri, Sep 30, 2016 at 2:43 AM, Claude Pache 
wrote:

> Besides U+2028 and U+2029, there is also the __proto__ key, which has a
> special meaning in JS as implemented in browser. That prevents definitely
> to "safely" embed arbitrary JSON within JS.
>
> —Claude
>
> Le 29 sept. 2016 à 23:21, Richard Gibson  a
> écrit :
>
> ECMAScript claims JSON as a subset twice in https://tc39.github.io/
> ecma262/#sec-json.parse , but (as has been well-documented) that is not
> true because it JSON strings can contain unescaped U+2028 LINE SEPARATOR
> and U+2029 PARAGRAPH SEPARATOR while ECMAScript strings cannot. Mark Miller
> alludes to a pre-ES5 push for allowing them (which ultimately failed) in
> https://esdiscuss.org/topic/json-stringify-script#content-17 , and posits
> that a repeat today would also fail. Having never seen a windmill that
> didn't need slaying, I hereby make the attempt.
>
> Aside from slightly simplifying the spec (by eliminating the need for a
> production specific to JSON.parse) and retroactively validating its claims,
> such a change to _DoubleStringCharacter_ and _SingleStringCharacter_ would
> allow safely embedding arbitrary JSON directly within ECMAScript, a request
> which has been made before in the context of source
> concatenation/construction.
>
> User-visible effects from the change would be limited to the absence of
> SyntaxError s from code like `eval(' "\u2028" ')` or its raw-text
> equivalent.
> ___
> 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: Feature Request: Make ECMA262 a superset of JSON

[Claude Pache]

Besides U+2028 and U+2029, there is also the __proto__ key, which has a special 
meaning in JS as implemented in browser. That prevents definitely to "safely" 
embed arbitrary JSON within JS.

—Claude

> Le 29 sept. 2016 à 23:21, Richard Gibson  a écrit :
> 
> ECMAScript claims JSON as a subset twice in 
> https://tc39.github.io/ecma262/#sec-json.parse 
>  , but (as has been 
> well-documented) that is not true because it JSON strings can contain 
> unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR while 
> ECMAScript strings cannot. Mark Miller alludes to a pre-ES5 push for allowing 
> them (which ultimately failed) in 
> https://esdiscuss.org/topic/json-stringify-script#content-17 
>  , and posits 
> that a repeat today would also fail. Having never seen a windmill that didn't 
> need slaying, I hereby make the attempt.
> 
> Aside from slightly simplifying the spec (by eliminating the need for a 
> production specific to JSON.parse) and retroactively validating its claims, 
> such a change to _DoubleStringCharacter_ and _SingleStringCharacter_ would 
> allow safely embedding arbitrary JSON directly within ECMAScript, a request 
> which has been made before in the context of source 
> concatenation/construction.
> 
> User-visible effects from the change would be limited to the absence of 
> SyntaxError s from code like `eval(' "\u2028" ')` or its raw-text equivalent.
> ___
> 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: Feature-Request: Add Range type data

[Dayvson Lima]

this feature request is inspired by the successful Range object behavior in
ruby language

http://ruby-doc.org/core-2.2.0/Range.html

the intention is to have something like interface to work with value ranges


2016-07-15 14:35 GMT-03:00 Steve Fink :

> On 07/14/2016 09:33 PM, Dayvson Lima wrote:
>
> Example:
>
> var myRange = new Range(0,4);
>
> myRange == (0..4)   #=> true
>
>
> This (0..4) syntax doesn't exist, afaik. Do you mean myRange ==
> [0,1,2,3,4]? Given that [1,2] != [1,2], I don't think so. I'm assuming you
> meant that as shorthand.
>
>
>
> new Array(myRange)  #=> [0, 1, 2, 3, 4]
>
>
> I'm not sure what this gives you over
>
>   var Range = function*(start, end) { let i = start; while (i <= end)
> yield i++; };
>
>   var myRange = Range(0, 4);
>   new Array(myRange); # [0, 1, 2, 3, 4], but it empties out myRange
>   [...Range(0, 4)]; # [0, 1, 2, 3, 4]
>
> var charRange = new Range('a', ' d');  #=> ('a'..'d')
>
>
> Ugh. This is very latin1-centric. What is 'a'..'d', again? a ä á à b ç c
> d, perhaps? (Yes, charCodeAt(0) offers a possible interpretation, but it's
> somewhat random.) And what is Range('aa', 'bb')? Range('a', 'bb')?
> Range('A', 'a')? Keep away from characters; they aren't numbers drawn from
> any useful 1-dimensional space.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 

*Dayvson Lima*

Front End Enginner - Safari Studio
Estagiário de Webdesign e Usabilidade no NTI - UFPE
Graduando em Análise e Desenvolvimento de Sistemas - IFPE Recife
Graduando em Gestão da Tecnologia da Informação (Primeiro ano concluído)
Vice campeão Worldskills (Etapa Estadual - PE) categoria Webdesign /
Webmaster
Técnico em Redes de computadores - SENAI Areias
Contato:(81) 8122-0466
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: Add Range type data

[Steve Fink]

On 07/14/2016 09:33 PM, Dayvson Lima wrote:

Example:

var myRange = new Range(0,4);

myRange == (0..4)   #=> true


This (0..4) syntax doesn't exist, afaik. Do you mean myRange == 
[0,1,2,3,4]? Given that [1,2] != [1,2], I don't think so. I'm assuming 
you meant that as shorthand.





new Array(myRange)  #=> [0, 1, 2, 3, 4]


I'm not sure what this gives you over

  var Range = function*(start, end) { let i = start; while (i <= end) 
yield i++; };


  var myRange = Range(0, 4);
  new Array(myRange); # [0, 1, 2, 3, 4], but it empties out myRange
  [...Range(0, 4)]; # [0, 1, 2, 3, 4]


var charRange = new Range('a', ' d');  #=> ('a'..'d')


Ugh. This is very latin1-centric. What is 'a'..'d', again? a ä á à b ç c 
d, perhaps? (Yes, charCodeAt(0) offers a possible interpretation, but 
it's somewhat random.) And what is Range('aa', 'bb')? Range('a', 'bb')? 
Range('A', 'a')? Keep away from characters; they aren't numbers drawn 
from any useful 1-dimensional space.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Isiah Meadows]

You could also solve the iterability this way with weak references:

```js
function *iter(wm) {
  for (const ref of wm._refs) {
const key = ref.get()
yield [key, wm.get(key)]
  }
}

function remove({wm, ref}) {
  wm._refs.remove(ref)
}

class IterableWeakMap extends WeakMap {
  constructor(list) {
super()
this._refs = new Set()
for (const e of list) this.set(e)
  }

  set(key, value) {
super.set(key, value)
const arg = {wm: this, ref: undefined}
arg.ref = makeWeakRef(e, remove, arg)
this._refs.add(arg.ref)
return this
  }

  forEach(callback, thisArg = undefined) {
for (const [key, value] of iter(this)) {
  f.call(thisArg, value, key)
}
  }

  [Symbol.iterator]() { return iter(this) }
  entries() { return iter(this) }

  keys() {
for (const [key] of iter(this)) yield key
  }

  values() {
for (const [, value] of iter(this)) yield value
  }

  clear() {
for (const ref of this._refs) {
  this.delete(ref.get())
}
this._refs.clear()
  }
}
```

On Thu, Jul 14, 2016, 06:55 Michał Wadas  wrote:

> What you think you need: iterable WeakMap
> What you really need: WeakReference, PhantomReference.
>
> Personally I think we need built-in class "GarbageCollectorObserver" that
> emit events for each observed collected object (uniquely identified by
> strongly-held symbols), it will solve most of problems associated with
> binding models and views.
>
>
> On Wed, Jul 13, 2016 at 2:13 PM, Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> Hi everyone,
>>
>> not sure, whether this is the right place for discussing a feature
>> request - and how to find out, whether this was already proposed/discussed
>> before and with which result... My google search did not bring up anything
>> about it.
>>
>> On my opinion it should be made possible to iterate over all elements in
>> a WeakSet & WeakMap. I already found many cases, in which I'd like to have
>> used the neat feature of "garbage collect the object, if it is not referred
>> to by others anymore", but with the necessity to know, which objects are in
>> the set (not only, if a given object is). An example:
>>
>> Registering callbacks to objects:
>>
>> class Foo {
>>   onBla(Handler) {
>> this.BlaSuperWeakMap.push(Handler);
>>   }
>>
>>   someOtherMethod() {
>> for (let X in this.BlaSuperWeakMap) {
>>   X();
>> }
>>   }
>>
>>   constructor() {
>> this.BlaSuperWeakMap = new SuperWeakMap();
>>   }
>> }
>>
>> const MyFoo = new Foo();
>> {
>>   let MyHandler1 = function(){
>> console.log('MyHandler1 called');
>>   };
>>   MyFoo.onBla(MyHandler1);
>>   console.log('Invokation1:');
>>   MyFoo.someOtherMethod();
>> }
>> let MyHandler2 = function(){
>>   console.log('MyHandler2 called');
>> };
>> MyFoo.onBla(MyHandler2);
>> MyFoo.onBla(function(){
>>   console.log('MyHandler3 called');
>> });
>> console.log('Invokation2:');
>> MyFoo.someOtherMethod();
>> MyHandler2 = undefined;
>> console.log('Invokation3:');
>> MyFoo.someOtherMethod();
>>
>> Expected result:
>>   Invokation1:
>>   MyHandler1 called
>>   Invokation2:
>>   MyHandler2 called
>>   Invokation3:
>>
>> Basically the example is: Invoke the callback of all objects which still
>> "exist" (in the meaning of having "non-weak" references towards them).
>>
>> I know this may have some caveats. It would be necessary to check the
>> reference count of the object in the SuperWeakSet, because the object may
>> have no "non-weak" references left but still was not yet garbage collected.
>> I do not know, whether current ECMAScript-Implementations and their garbage
>> collecting solutions could handle this easily - basically it is the same
>> decision, which the garbage collector would make: If an object can be
>> disposed, because it has no non-Weak references pointing to it, the object
>> is by definition not in the WeakSet anymore. And implementations could in
>> that case even give a hint to the garbage collector, which may improve
>> performance of applications, which use the SuperWeakSet alot.
>>
>> Greetings, 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Michał Wadas]

What you think you need: iterable WeakMap
What you really need: WeakReference, PhantomReference.

Personally I think we need built-in class "GarbageCollectorObserver" that
emit events for each observed collected object (uniquely identified by
strongly-held symbols), it will solve most of problems associated with
binding models and views.


On Wed, Jul 13, 2016 at 2:13 PM, Michael Kriegel <
michael.krie...@actifsource.com> wrote:

> Hi everyone,
>
> not sure, whether this is the right place for discussing a feature request
> - and how to find out, whether this was already proposed/discussed before
> and with which result... My google search did not bring up anything about
> it.
>
> On my opinion it should be made possible to iterate over all elements in a
> WeakSet & WeakMap. I already found many cases, in which I'd like to have
> used the neat feature of "garbage collect the object, if it is not referred
> to by others anymore", but with the necessity to know, which objects are in
> the set (not only, if a given object is). An example:
>
> Registering callbacks to objects:
>
> class Foo {
>   onBla(Handler) {
> this.BlaSuperWeakMap.push(Handler);
>   }
>
>   someOtherMethod() {
> for (let X in this.BlaSuperWeakMap) {
>   X();
> }
>   }
>
>   constructor() {
> this.BlaSuperWeakMap = new SuperWeakMap();
>   }
> }
>
> const MyFoo = new Foo();
> {
>   let MyHandler1 = function(){
> console.log('MyHandler1 called');
>   };
>   MyFoo.onBla(MyHandler1);
>   console.log('Invokation1:');
>   MyFoo.someOtherMethod();
> }
> let MyHandler2 = function(){
>   console.log('MyHandler2 called');
> };
> MyFoo.onBla(MyHandler2);
> MyFoo.onBla(function(){
>   console.log('MyHandler3 called');
> });
> console.log('Invokation2:');
> MyFoo.someOtherMethod();
> MyHandler2 = undefined;
> console.log('Invokation3:');
> MyFoo.someOtherMethod();
>
> Expected result:
>   Invokation1:
>   MyHandler1 called
>   Invokation2:
>   MyHandler2 called
>   Invokation3:
>
> Basically the example is: Invoke the callback of all objects which still
> "exist" (in the meaning of having "non-weak" references towards them).
>
> I know this may have some caveats. It would be necessary to check the
> reference count of the object in the SuperWeakSet, because the object may
> have no "non-weak" references left but still was not yet garbage collected.
> I do not know, whether current ECMAScript-Implementations and their garbage
> collecting solutions could handle this easily - basically it is the same
> decision, which the garbage collector would make: If an object can be
> disposed, because it has no non-Weak references pointing to it, the object
> is by definition not in the WeakSet anymore. And implementations could in
> that case even give a hint to the garbage collector, which may improve
> performance of applications, which use the SuperWeakSet alot.
>
> Greetings, 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: Feature-Request: allow to iterate over WeakSet / WeakMap

[Allen Wirfs-Brock]

> On Jul 13, 2016, at 9:45 AM, Michael Kriegel  > wrote:
> 
> Wouldn't it be preferable to discuss, whether the requested feature makes 
> sense or not, before looking at whether it is possible to easily implement it 
> in the current garbage collectors on the market?

But that discussion has already taken place within TC39 (and on es-discuss) 
during the development of WeakMap/WeakSet.

Also, this isn’t about markets, it’s about technical feasibility. Nobody knows 
how to implement a 0 latency, totally deterministic, low overhead GC.  It’s 
likely that such a thing isn't even possible given current 
processor/memory/software architectures. 


> 
> On 13.07.2016 18:11, Allen Wirfs-Brock wrote:
>> 
>>> On Jul 13, 2016, at 7:18 AM, Michael Kriegel 
>>> > 
>>> wrote:
>>> 
>>> I am not sure, which kinds of garbage collectors the implementations of 
>>> ECMAScript typically use. If they used a reference counter, which counts 
>>> "non-weak" references only, a simple check, whether the reference count is 
>>> 0 or not on access to a weak reference would be sufficient.
>> 
>> Reference counting is not “garbage collection” because reference counting 
>> can not recover circular chains of object references.
> 
> Of course not. However, reference counting can recover from circular chains. 
> Example:

That statement simply demonstrates that you aren’t well schooled in memory 
management technology.  If you want to be taken seriously, please educate 
yourself.

> 
> imagine, deleting a hard reference internally invokes deleteReference with 
> following implementation:
> 
> deleteReferenceTo(Obj) {
>   ReferenceCount[Obj]--;
>   if (ReferenceCount[Obj] === 0) {
> for (Key in Object.getOwnProperties(Obj)) {
>   delete Obj[Key];
> }
>   }
> }
> 
> delete Obj[Key] will call deleteReference. Once this delete call returns, 
> there may be no further reference to the object Obj[Key] referred to. Then 
> delete recursion occurs for that object. If there is a circle of objects 
> without any further hard references to, the recursion will end, as the 
> properties of the objects are deleted immediately. But as the object has no 
> references to it anyway, deleting its properties is not an issue.
> 
>> 
>> Modern garbage collector are complex heuristic-based beasts that try to make 
>> good trade-offs between latency (how long does an object continue to consume 
>> storage after it actually becomes unreferenced)  and performance (how much 
>> of the total processing cycles is consume trying to recover unreferenced 
>> objects).  Each implementation’s GC uses different heuristics to optimize 
>> that trade-off.  Thus when any given object would will be observably GC'ed 
>> is non-deterministic between implementations (and often even within a 
>> particular implementation).
>> 
> 

consider:

var ref = {x: null};  //ref count of object is 1
ref.x=ref;//ref count of object is 2; 
ref = null;//after internally calling deleteReferenceTo, ref count of 
object is 1.
//  the object is now unreachable, but has a non-zero reference count. It has 
not been deallocated

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Michael Kriegel]

Wouldn't it be preferable to discuss, whether the requested feature 
makes sense or not, before looking at whether it is possible to easily 
implement it in the current garbage collectors on the market?


On 13.07.2016 18:11, Allen Wirfs-Brock wrote:


On Jul 13, 2016, at 7:18 AM, Michael Kriegel 
> wrote:


I am not sure, which kinds of garbage collectors the implementations 
of ECMAScript typically use. If they used a reference counter, which 
counts "non-weak" references only, a simple check, whether the 
reference count is 0 or not on access to a weak reference would be 
sufficient.


Reference counting is not “garbage collection” because reference 
counting can not recover circular chains of object references.


Of course not. However, reference counting can recover from circular 
chains. Example:


imagine, deleting a hard reference internally invokes deleteReference 
with following implementation:


deleteReferenceTo(Obj) {
  ReferenceCount[Obj]--;
  if (ReferenceCount[Obj] === 0) {
for (Key in Object.getOwnProperties(Obj)) {
  delete Obj[Key];
}
  }
}

delete Obj[Key] will call deleteReference. Once this delete call 
returns, there may be no further reference to the object Obj[Key] 
referred to. Then delete recursion occurs for that object. If there is a 
circle of objects without any further hard references to, the recursion 
will end, as the properties of the objects are deleted immediately. But 
as the object has no references to it anyway, deleting its properties is 
not an issue.




Modern garbage collector are complex heuristic-based beasts that try 
to make good trade-offs between latency (how long does an object 
continue to consume storage after it actually becomes unreferenced) 
 and performance (how much of the total processing cycles is consume 
trying to recover unreferenced objects).  Each implementation’s GC 
uses different heuristics to optimize that trade-off.  Thus when any 
given object would will be observably GC'ed is non-deterministic 
between implementations (and often even within a particular 
implementation).




Sure and that is good as it is. Weak references as I'd like to see them, 
would depend on the information, whether there is still a hard reference 
to the object - not whether it has actually been gc'ed. However, I'll 
have to take a deeper look into thegc topic to find out, whether there 
is no way to find that out - still please note the first question in 
this message: does the requested feature make sense?


On my opinion: yes, because when the user can declare weak references 
explicitely, he can rely on that an object will be gc'ed even though he 
still has a weak reference to it. Of course he has to assure, that the 
resource still "exists":


let x = {};
let weak y = x

function someFunctionWhichUsesY() {
  if (y) y['a']++;
  // maybe: else throw ...
}

function someOtherFunctionWhichDeletesTheOnlyHardReferenceToX() {
  x = {'a':0}; // user may not have noticed, that y is still pointing 
to the original object - but as y is weak, it will be undefined from now 
on -> no memory leak.

}

If the user forgets to check for y's existence and 
someOtherFunctionWhichDeletesTheOnlyHardReferenceToX has been called 
before, an exception, but that is much better than having a memory leak 
(if you ask me). Again: On my opinion a weak reference should return 
undefined as soon as there is no hard reference to the object anymore, 
not as soon as the object becomes gc'ed.




If you want to drill deep into how garbage collectors work, there are 
lots of good resources at http://www.memorymanagement.org/index.html



Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Allen Wirfs-Brock]

> On Jul 13, 2016, at 7:18 AM, Michael Kriegel  > wrote:
> 
> I am not sure, which kinds of garbage collectors the implementations of 
> ECMAScript typically use. If they used a reference counter, which counts 
> "non-weak" references only, a simple check, whether the reference count is 0 
> or not on access to a weak reference would be sufficient.

Reference counting is not “garbage collection” because reference counting can 
not recover circular chains of object references.

Modern garbage collector are complex heuristic-based beasts that try to make 
good trade-offs between latency (how long does an object continue to consume 
storage after it actually becomes unreferenced)  and performance (how much of 
the total processing cycles is consume trying to recover unreferenced objects). 
 Each implementation’s GC uses different heuristics to optimize that trade-off. 
 Thus when any given object would will be observably GC'ed is non-deterministic 
between implementations (and often even within a particular implementation). 

If you want to drill deep into how garbage collectors work, there are lots of 
good resources at http://www.memorymanagement.org/index.html 
 


Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Boris Zbarsky]

On 7/13/16 10:59 AM, Michael Kriegel wrote:

So what does gc do to determine, whether an object still has hard
references pointing towards it?


The GC may be conservative, not be precise.  That is, it may not collect 
some stuff that actually could be collected because the GC thinks there 
are references to it, while there actually aren't any.  The stuff may 
then end up being collected on a later collection, again depending on 
the contents of things like the machine stack and machine registers.



Depends on how the gc works. If "deleting the last reference to an
object" leads to an immediate deletion of all references to other
objects held by this object, then: no.


I'm not aware of any JS GC that uses reference counting.  It _could_ be 
done, together with a cycle collector, but you'd really really need the 
cycle collector.  And once you have a cycle collector, you need to run 
it to find out whether things really are unreachable; just looking at 
reference counts is no longer enough.



Any resources on what they do? E.g. chrome V8 or Firefox?


SpiderMonkey (the JS engine in Firefox) uses a tracing GC.  In terms of 
the "implementation strategies" described at 
https://en.wikipedia.org/wiki/Tracing_garbage_collection it's a moving, 
mark-and-sweep, generational, incremental, precise collector.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Michael Kriegel]

On 13.07.2016 16:27, Boris Zbarsky wrote:

On 7/13/16 10:18 AM, Michael Kriegel wrote:

But shouldn't it be predictable, whether there
are still "non-weak" references to an object?


Maybe.  The GC may include a machine stack scanner to root things 
referenced on the stack, which can give false positives depending on 
what integers happen to be hanging out on the stack.


So what does gc do to determine, whether an object still has hard 
references pointing towards it?




does NOT depend on, whether the object has actually been gc'ed, but 
whether the object does

have "non-weak" references to it.


Determining this basically requires running a full gc, no?


Depends on how the gc works. If "deleting the last reference to an 
object" leads to an immediate deletion of all references to other 
objects held by this object, then: no.





I am not sure, which kinds of garbage collectors the implementations of
ECMAScript typically use. If they used a reference counter


They don't.


Any resources on what they do? E.g. chrome V8 or Firefox?



-Boris
___
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: Feature-Request: allow to iterate over WeakSet / WeakMap

[Boris Zbarsky]

On 7/13/16 10:18 AM, Michael Kriegel wrote:

But shouldn't it be predictable, whether there
are still "non-weak" references to an object?


Maybe.  The GC may include a machine stack scanner to root things 
referenced on the stack, which can give false positives depending on 
what integers happen to be hanging out on the stack.



does NOT depend on, whether the object has actually been gc'ed, but whether the 
object does
have "non-weak" references to it.


Determining this basically requires running a full gc, no?


I am not sure, which kinds of garbage collectors the implementations of
ECMAScript typically use. If they used a reference counter


They don't.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Michael Kriegel]

I see the points in that thread, but I am not sure, whether I completely 
understand them. I can imagine, that there is an issue, because gc is 
somewhat unpredictable. But shouldn't it be predictable, whether there 
are still "non-weak" references to an object? So my intention slightly 
differs from what WeakSet/WeakMap (and WeakReference would) do: whether 
an object is in the SuperWeakSet (or a key in the SuperWeakMap, or a 
SuperWeakReference still points to the object) does NOT depend on, 
whether the object has actually been gc'ed, but whether the object does 
have "non-weak" references to it.


I am not sure, which kinds of garbage collectors the implementations of 
ECMAScript typically use. If they used a reference counter, which counts 
"non-weak" references only, a simple check, whether the reference count 
is 0 or not on access to a weak reference would be sufficient.


Of course, when I iterate through a WeakSet (respectively the keys of a 
WeakMap), in the beginning of the iteration, a keys-array needs to be 
retrieved, which is an array of all objects in the weak set, which have 
reference count > 0 at that point in time. As this array then holds hard 
references to all key objects, the key array cannot be changed by gc 
during iteration.


On 13.07.2016 15:14, Bradley Meck wrote:
This thread from 2011 might help understand why they should not be 
enumerable (it links to another thread as well inside). 
https://mail.mozilla.org/pipermail/es-discuss/2011-April/013604.html


On Wed, Jul 13, 2016 at 8:08 AM, Isiah Meadows > wrote:


Could you explain a real world use case for this? I recall some
that it would've simplified some, but the best implementation
often didn't even require iteration, but just changing the data
layout altogether.


On Wed, Jul 13, 2016, 08:13 Michael Kriegel
> wrote:

Hi everyone,

not sure, whether this is the right place for discussing a feature
request - and how to find out, whether this was already
proposed/discussed before and with which result... My google
search did
not bring up anything about it.

On my opinion it should be made possible to iterate over all
elements in
a WeakSet & WeakMap. I already found many cases, in which I'd
like to
have used the neat feature of "garbage collect the object, if
it is not
referred to by others anymore", but with the necessity to
know, which
objects are in the set (not only, if a given object is). An
example:

Registering callbacks to objects:

class Foo {
   onBla(Handler) {
 this.BlaSuperWeakMap.push(Handler);
   }

   someOtherMethod() {
 for (let X in this.BlaSuperWeakMap) {
   X();
 }
   }

   constructor() {
 this.BlaSuperWeakMap = new SuperWeakMap();
   }
}

const MyFoo = new Foo();
{
   let MyHandler1 = function(){
 console.log('MyHandler1 called');
   };
   MyFoo.onBla(MyHandler1);
   console.log('Invokation1:');
   MyFoo.someOtherMethod();
}
let MyHandler2 = function(){
   console.log('MyHandler2 called');
};
MyFoo.onBla(MyHandler2);
MyFoo.onBla(function(){
   console.log('MyHandler3 called');
});
console.log('Invokation2:');
MyFoo.someOtherMethod();
MyHandler2 = undefined;
console.log('Invokation3:');
MyFoo.someOtherMethod();

Expected result:
   Invokation1:
   MyHandler1 called
   Invokation2:
   MyHandler2 called
   Invokation3:

Basically the example is: Invoke the callback of all objects
which still
"exist" (in the meaning of having "non-weak" references
towards them).

I know this may have some caveats. It would be necessary to
check the
reference count of the object in the SuperWeakSet, because the
object
may have no "non-weak" references left but still was not yet
garbage
collected. I do not know, whether current
ECMAScript-Implementations and
their garbage collecting solutions could handle this easily -
basically
it is the same decision, which the garbage collector would
make: If an
object can be disposed, because it has no non-Weak references
pointing
to it, the object is by definition not in the WeakSet anymore. And
implementations could in that case even give a hint to the garbage
collector, which may improve performance of applications,
which use the
SuperWeakSet alot.

Greetings, Michael

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Michael Kriegel]

Sure.

I am using an MVC pattern, where model changes are notified via events. 
Multiple views, lets call two of them view1 and view2, are capable of 
displaying an object X, which is in the model. Whenever X is modified 
(in the sense of modifying a property of it) an event is fired. Views, 
which display an aspect of X register themselves to the modified-event 
of X to be refreshed. However, views may be closed, so a view which was 
closed shall be unsubscribed from that event automatically. Without an 
iterable WeakSet, I have to unsubscribe the view manually on disposal. 
This is more error prone, as different views subscribe to different 
model change events, so each of my views needs kind of a destructor, 
which unregisters it from all such event handlers, which it registered 
to - if you forget one, you have a memory leak.


Actually ECMAScript should introduce WeakReference, which is sth. like a 
variable, which may lose its object, when no "non-Weak" reference to it 
exists anymore. Losing the value means it returns undefined again. example:


let a = {};
let weak b = a;
console.log(typeof(b)); // prints object
a = {};
console.log(typeof(b)); // prints undefined

Having WeakReferences and iterable WeakSet/WeakMap would help a lot in 
preventing memory leaks.


Of course, as stated before: it would be preferred, if the WeakReference 
/ WeakSet / WeakMap is predictable in the sense, that their state does 
not depend on "whether an object has actually been garbage collected", 
but on "whether an object still has 'non-weak' references pointing to 
it, aka 'is garbage-collectable". Of course this involves checking 
garbage-collectability on access to the WeakReference / WeakSet / WeakMap.


On 13.07.2016 15:08, Isiah Meadows wrote:


Could you explain a real world use case for this? I recall some that 
it would've simplified some, but the best implementation often didn't 
even require iteration, but just changing the data layout altogether.



On Wed, Jul 13, 2016, 08:13 Michael Kriegel 
> wrote:


Hi everyone,

not sure, whether this is the right place for discussing a feature
request - and how to find out, whether this was already
proposed/discussed before and with which result... My google
search did
not bring up anything about it.

On my opinion it should be made possible to iterate over all
elements in
a WeakSet & WeakMap. I already found many cases, in which I'd like to
have used the neat feature of "garbage collect the object, if it
is not
referred to by others anymore", but with the necessity to know, which
objects are in the set (not only, if a given object is). An example:

Registering callbacks to objects:

class Foo {
   onBla(Handler) {
 this.BlaSuperWeakMap.push(Handler);
   }

   someOtherMethod() {
 for (let X in this.BlaSuperWeakMap) {
   X();
 }
   }

   constructor() {
 this.BlaSuperWeakMap = new SuperWeakMap();
   }
}

const MyFoo = new Foo();
{
   let MyHandler1 = function(){
 console.log('MyHandler1 called');
   };
   MyFoo.onBla(MyHandler1);
   console.log('Invokation1:');
   MyFoo.someOtherMethod();
}
let MyHandler2 = function(){
   console.log('MyHandler2 called');
};
MyFoo.onBla(MyHandler2);
MyFoo.onBla(function(){
   console.log('MyHandler3 called');
});
console.log('Invokation2:');
MyFoo.someOtherMethod();
MyHandler2 = undefined;
console.log('Invokation3:');
MyFoo.someOtherMethod();

Expected result:
   Invokation1:
   MyHandler1 called
   Invokation2:
   MyHandler2 called
   Invokation3:

Basically the example is: Invoke the callback of all objects which
still
"exist" (in the meaning of having "non-weak" references towards them).

I know this may have some caveats. It would be necessary to check the
reference count of the object in the SuperWeakSet, because the object
may have no "non-weak" references left but still was not yet garbage
collected. I do not know, whether current
ECMAScript-Implementations and
their garbage collecting solutions could handle this easily -
basically
it is the same decision, which the garbage collector would make: If an
object can be disposed, because it has no non-Weak references pointing
to it, the object is by definition not in the WeakSet anymore. And
implementations could in that case even give a hint to the garbage
collector, which may improve performance of applications, which
use the
SuperWeakSet alot.

Greetings, Michael









___
es-discuss mailing list
es-discuss@mozilla.org 
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Bradley Meck]

This thread from 2011 might help understand why they should not be
enumerable (it links to another thread as well inside).
https://mail.mozilla.org/pipermail/es-discuss/2011-April/013604.html

On Wed, Jul 13, 2016 at 8:08 AM, Isiah Meadows 
wrote:

> Could you explain a real world use case for this? I recall some that it
> would've simplified some, but the best implementation often didn't even
> require iteration, but just changing the data layout altogether.
>
> On Wed, Jul 13, 2016, 08:13 Michael Kriegel <
> michael.krie...@actifsource.com> wrote:
>
>> Hi everyone,
>>
>> not sure, whether this is the right place for discussing a feature
>> request - and how to find out, whether this was already
>> proposed/discussed before and with which result... My google search did
>> not bring up anything about it.
>>
>> On my opinion it should be made possible to iterate over all elements in
>> a WeakSet & WeakMap. I already found many cases, in which I'd like to
>> have used the neat feature of "garbage collect the object, if it is not
>> referred to by others anymore", but with the necessity to know, which
>> objects are in the set (not only, if a given object is). An example:
>>
>> Registering callbacks to objects:
>>
>> class Foo {
>>onBla(Handler) {
>>  this.BlaSuperWeakMap.push(Handler);
>>}
>>
>>someOtherMethod() {
>>  for (let X in this.BlaSuperWeakMap) {
>>X();
>>  }
>>}
>>
>>constructor() {
>>  this.BlaSuperWeakMap = new SuperWeakMap();
>>}
>> }
>>
>> const MyFoo = new Foo();
>> {
>>let MyHandler1 = function(){
>>  console.log('MyHandler1 called');
>>};
>>MyFoo.onBla(MyHandler1);
>>console.log('Invokation1:');
>>MyFoo.someOtherMethod();
>> }
>> let MyHandler2 = function(){
>>console.log('MyHandler2 called');
>> };
>> MyFoo.onBla(MyHandler2);
>> MyFoo.onBla(function(){
>>console.log('MyHandler3 called');
>> });
>> console.log('Invokation2:');
>> MyFoo.someOtherMethod();
>> MyHandler2 = undefined;
>> console.log('Invokation3:');
>> MyFoo.someOtherMethod();
>>
>> Expected result:
>>Invokation1:
>>MyHandler1 called
>>Invokation2:
>>MyHandler2 called
>>Invokation3:
>>
>> Basically the example is: Invoke the callback of all objects which still
>> "exist" (in the meaning of having "non-weak" references towards them).
>>
>> I know this may have some caveats. It would be necessary to check the
>> reference count of the object in the SuperWeakSet, because the object
>> may have no "non-weak" references left but still was not yet garbage
>> collected. I do not know, whether current ECMAScript-Implementations and
>> their garbage collecting solutions could handle this easily - basically
>> it is the same decision, which the garbage collector would make: If an
>> object can be disposed, because it has no non-Weak references pointing
>> to it, the object is by definition not in the WeakSet anymore. And
>> implementations could in that case even give a hint to the garbage
>> collector, which may improve performance of applications, which use the
>> SuperWeakSet alot.
>>
>> Greetings, 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Isiah Meadows]

Could you explain a real world use case for this? I recall some that it
would've simplified some, but the best implementation often didn't even
require iteration, but just changing the data layout altogether.

On Wed, Jul 13, 2016, 08:13 Michael Kriegel 
wrote:

> Hi everyone,
>
> not sure, whether this is the right place for discussing a feature
> request - and how to find out, whether this was already
> proposed/discussed before and with which result... My google search did
> not bring up anything about it.
>
> On my opinion it should be made possible to iterate over all elements in
> a WeakSet & WeakMap. I already found many cases, in which I'd like to
> have used the neat feature of "garbage collect the object, if it is not
> referred to by others anymore", but with the necessity to know, which
> objects are in the set (not only, if a given object is). An example:
>
> Registering callbacks to objects:
>
> class Foo {
>onBla(Handler) {
>  this.BlaSuperWeakMap.push(Handler);
>}
>
>someOtherMethod() {
>  for (let X in this.BlaSuperWeakMap) {
>X();
>  }
>}
>
>constructor() {
>  this.BlaSuperWeakMap = new SuperWeakMap();
>}
> }
>
> const MyFoo = new Foo();
> {
>let MyHandler1 = function(){
>  console.log('MyHandler1 called');
>};
>MyFoo.onBla(MyHandler1);
>console.log('Invokation1:');
>MyFoo.someOtherMethod();
> }
> let MyHandler2 = function(){
>console.log('MyHandler2 called');
> };
> MyFoo.onBla(MyHandler2);
> MyFoo.onBla(function(){
>console.log('MyHandler3 called');
> });
> console.log('Invokation2:');
> MyFoo.someOtherMethod();
> MyHandler2 = undefined;
> console.log('Invokation3:');
> MyFoo.someOtherMethod();
>
> Expected result:
>Invokation1:
>MyHandler1 called
>Invokation2:
>MyHandler2 called
>Invokation3:
>
> Basically the example is: Invoke the callback of all objects which still
> "exist" (in the meaning of having "non-weak" references towards them).
>
> I know this may have some caveats. It would be necessary to check the
> reference count of the object in the SuperWeakSet, because the object
> may have no "non-weak" references left but still was not yet garbage
> collected. I do not know, whether current ECMAScript-Implementations and
> their garbage collecting solutions could handle this easily - basically
> it is the same decision, which the garbage collector would make: If an
> object can be disposed, because it has no non-Weak references pointing
> to it, the object is by definition not in the WeakSet anymore. And
> implementations could in that case even give a hint to the garbage
> collector, which may improve performance of applications, which use the
> SuperWeakSet alot.
>
> Greetings, 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: Feature Request: Number.isNumber()

[Adrian Sieber]

>
> What about Number.isFinite?
>
Thanks for the heads up. I wasn't aware that there was a fixed version of
`isFinite` added to ES2015.
The global one was just a mess , but the new one seems to do
exactly what I was looking for. Problem solved =). Thanks a lot!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Request: Number.isNumber()

[Álex Puchades]

El 10/4/2016 5:08 PM, "Adrian Sieber"  escribió:
>
> Hi everybody,
>
> checking if a value is a number is currently really complicated and
> I have stumbled upon a fair amount of code where this lead to bugs.
>
> The easiest way is `typeof value === 'number'`.

What about Number.isFinite?

> This however has the drawback that `NaN` also evaluates to true.

Number.isFinite(NaN) is `false`

> Furthermore, basically every expression preceded by a `+` evaluates to
true.
> … and there are even more gotchas. For a full roundup read
https://github.com/jonschlinkert/is-number.
>
> This implementation could also be used as a starting point.
> (However, I would argue that `isNumber('3')` should evaluate to false.
> It's a string after all.)
>
> Therefore I think a `isNumber` functionality should already be provided
natively.
> What do you think?
>
> ___
> 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: Feature Request : Access Closures of a function, outside of the Function!

[Isiah Meadows]

Oh, and closures being accessible outside of them also would have huge
memory implications. IMHO that's when you start just using traditional OOP,
and bind methods where necessary.

On Sun, Mar 13, 2016, 20:42 Gorgi Kosev  wrote:

> Have you tried experimenting with babel to achieve this? Here is a
> starting point for a transform that makes all arrow functions behave this
> way: https://gist.github.com/spion/adc5b0110f9466efc0a2 (note: may need
> more work)
>
> Unfortunately, as far as I know whole new type of function would probably
> have to be introduced for this. Some security capabilities of JS are based
> on closure captures being inaccessible outside their scope.
> ___
> 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: Feature Request : Access Closures of a function, outside of the Function!

[Gorgi Kosev]

Have you tried experimenting with babel to achieve this? Here is a starting
point for a transform that makes all arrow functions behave this way:
https://gist.github.com/spion/adc5b0110f9466efc0a2 (note: may need more
work)

Unfortunately, as far as I know whole new type of function would probably
have to be introduced for this. Some security capabilities of JS are based
on closure captures being inaccessible outside their scope.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss