I just can't help but imagine those long lived rats escaping and taking over our cities. We already struggle with the rat population and they only live 3 years, imagine if they lived 15.
Also I love rats and totally agree they're tough pets because they don't live long enough. We had many of them growing up and spent a fortune removing tumors.
I thought rats would make great pets but the idea that you get attached to a guy who would die in a couple years is quite discouraging. You updated my knowledge.
My grandmother had an African grey parrot she had inherited from someone.
Hey there, sorry to confuse you but that was a bit of a joke, real rats max lifespan is 7, but we have those other rats that will live to 80 or even 90... But yes, the parrot issue is real, people will get those without thinking for even a second about how old they can get. We have one in our family that has outlived three owners.
AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.
Browsers have said that they are unwilling to ship any new cancelation mechanisms given that AbortSignal already exists, so we can't ship a different CancelToken. But I think there's a path to standardizing a subset of the existing AbortSignal machinery [1].
(I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of committee.)
Yes, I was around during the original discussions. AbortSignal exists because TC39 was taking too long and cancelling fetch() is table stakes for a networking oriented platform like the web.
Those threads are a good example of what's wrong in TC39. A simple AbortSignal could have been added, but by the time it's reconciled with SES, large speculative APIs like Governers, or the original attempt to add a parallel throw mechanism just for cancellation, nothing actually gets done.
It's been 10 years since CancelToken was first discussed and we're still debating it.
I agree that the original cancellation discussion was bad. I don't agree that these threads reflect the same disfunction. They're a new effort (from me). No one was working on it previously because browsers have said that they were unwilling to add any other form of cancellation given that AbortSignal already exists, so there was never a chance to add a separate CancelToken once it shipped. The work to be done now is basically administrative: moving a subset from the WHATWG spec to TC39. This has ~no relevance to user's lives unless they're using a JS runtime which does not implement the WinterTC spec, which is approximately no one. The delay has nothing to do with SES (which has no bearing on this), and Governors are a _use case_ which motivates bringing it into the language, not a thing with which it needs to be reconciled.
Hard disagree, TC39 has done great work over the last 10 years. To name a few:
- Async/await
- Rest/spread
- Async iterators
- WeakRefs
- Explicit Resource Management
- Temporal
It's decisions are much more well thought out than WHATWG standards. AbortSignal extending from EventTarget was a terrible call.
More good works from the last 10 years includes .at(), nullish chaining, BigInt etc.
But most of what you mentioned is closing in on 10 years in the standard (Async/Await is from 2017) meaning the bulk of the work done is from over 10 years ago.
The failure of AbortSignal is exactly the kind of failure TC39 has been doing in bulk lately. I have been following the proposal to add Observables to the language, which is a stage 1 proposal (and has been for over 10 years!!!). There were talks 5 years ago (!) to align the API with AbortSignal[1] which I think really exemplifies the inability for TC39 to reach a workable decision (at least as it operates now).
Another example I like to bring up are the failure of the pipeline operator[2], which was advanced to stage-2 four years ago and has been in hiatus ever since with very little work to show for it. After years of deliberation very controversal version of the operator with a massive community backlash. Before they advanced it it was one of the more popular proposals, now, not so much, and personally I sense any enthusiasm for this feature has pretty much vanished. In other words I think they took half a decade to make the obviously wrong decision, and have since given up.
From the failure of the pipeline operator followed a bunch of half-measures such as array grouping, and iterator helpers etc. which could have easily been implemented in userland libraries if the more functional version of the pipeline operator would have advanced.
It can request with a JS call. It can't passively collect it without you approving first. The article is written like calling that JS function will turn on location tracking without consent.
That would allow you to see the local network IP (not actually sure you even get that, tbh). To get more detailed information about IP configuration, you need Location permission. Been there, done that. Most Android network information calls provide degraded information if you have not been granted Location permissions.
https://en.wikipedia.org/wiki/Attention_(machine_learning)
reply