This was probably the single worst design decision of JavaScript. It is the only language I know of that has two "absent value" types. If null was a billion dollar mistake, then undefined adds an order of magnitude to the problem. There is absolutely no reason for undefined to exist.
We've generally adopted strict mode. I think it is now time to come up with and adopt a new no-undefined mode. And yes, it should break the standard library. It is worth it.
> It is the only language I know of that has two "absent value" types.
It's not very common but not unique either. Perl has `undef` that roughly works identically, which became generalized into the "undefinedness" concept in Raku [1]. Ruby doesn't have `undef` value, but it could have been in the alternative universe [2]. Even more languages have multiple absent values which are not necessarily compatible to the null-undef distinction (e.g. Objective-C).
---
I think the separate `undef` value was mainly regarded as a solution to the apparent problem of detecting the absence in general, for example the absence of index or argument. Consider the following Python program for example:
def foo(obj=None): ...
It is clear that the optional `obj` argument cannot alone distinguish `foo(obj=None)` from `foo()`. A common idiom is to have a private object in place of `None`:
It is still possible to somehow obtain a reference to `_NOT_GIVEN` and therefore use `foo(obj=_NOT_GIVEN)` which is indistinguishable from `foo()`, but why would you do that? `None` is sometimes a valid argument to the optional argument, but `_NOT_GIVEN` is clearly designated to be invalid for that. Now rename `_NOT_GIVEN` and make it a language construct---voila, you've got `undef`.
`Undef` might have been a working solution a decade ago, when we were still struggling with dynamically typed languages in general and systematic approaches were less common. Lua for example uses `nil` for both purposes; `t[key] = nil` is a valid way to remove given key from the table `t` (with a caveat that it doesn't shift any subsequent keys if the key was an integer) and an excess argument is filled with `nil` [3]. This is painful from time to time, say, a table of optional integers is not straightforward. `Undef` might have been a good compromise under this observation... if we didn't have any algebraic/sum data type like today.
[3] Lua even tried hard to remove any visible distinction between the actual `nil` and real absence of value! But it's still not perfect, and the discrepancy is much easier to detect from the C API.
I mean, it's common when the argument itself has a domain of all possible Python objects and therefore `None` should be usable as a literal value. The requirement itself is not very common, but virtually all code with that requirement uses this idiom in my knowledge.
I believe the whole project, and the talk of stores in particular, is humour. At least that's how I read it. I appreciate not everyone has the same sense of humour so that may have passed you by.
I would start with Scratch and then move to a Basic with 2D drawing capabilities and then to Blitz3D which is a Basic with a 3D engine. Have a look at all the positive reviews.
> Revocation is essentially the Achilles heel of JWTs
By the nature of the problem you have to store some kind of a list of tokens. Either a black list as with JWTs or a white list as with classic session tokens. There is no way around it. This makes both approaches practically the same.
One can argue that the black list will in general be shorter than the white list, but in a case of a serious attack, would it really be so?
I am afraid that the community will now abandon JWTs and move to biscuits, macaroons, buns and meringues as they did with classic session tokens, throwing away the tools and security practices.
A simpler, but less targeted approach that works in case you're not tracking token issuance by ID is to maintain a list of maps of entity (e.g user) ID to minimum issue time. This way you can revoke all earlier tokens for a user ID with a single record, and not have to keep track of issued tokens.
In the case of a serious attack, the blacklist should be every token. You can still handle this quite nicely with JWT by rotating the previous verification key. Depends on systems and configuration, this can be as easy as changing the HMAC private key or push a new RSA key to every verifier.
My grandmother made it to 98, she rode horses when she was a younger woman (in Australia during the war, she was able to follow my grandfather who was an RAF mechanic out there on the last passenger ship through the Suez).
She used to enjoy a tipple, never smoked though, but in her later years never really exercised.
AR is for seeing what the customer is seeing and feeding customized ads and specialized offers. It is the ability to show smaller prices to poor and bigger prices to wealthy, increasing margins. It is an invaluable tool for marketers. It is potentially big big money for Facebook but meager offering for customers. VR is for luring users into AR advertising dystopia. Metaverse is a masquerade. Too bad for them they spent so much on the 3D red herring.
I can give an example. If something moves back in time, it interacts as if it has negative mass relative to us, who move forward in time. Of course nothing moves back in time but tachyons which exist only on paper. The worlds of things moving forward in time and backward in time never meet because they are just two different solutions to the same equation and we have absolutely no evidence that the second world exists. Inverted matter from Tenet should have received negative mass but we most likely will never see it because time may be an illusion likewise to rotation.
We've generally adopted strict mode. I think it is now time to come up with and adopt a new no-undefined mode. And yes, it should break the standard library. It is worth it.
reply