Its hypothetically possible to recreate this approach in any language. Grab the item in the map at that key -> check that it exists -> check that the type is what you expect.

Its not idiomatic in most mainstream languages. Except, that's how most JSON libraries which validate against a static structure are implemented, they just abstract the reflection away via some interface.

> Its hypothetically possible to recreate this approach in any language.

Yes, I didn't mean to imply that I was providing an exhaustive list of languages where this approach could be implemented. I merely mentioned Python because it had been brought up several times in the thread.

> Grab the item in the map at that key -> check that it exists -> check that the type is what you expect.

I'd argue with that phrasing. You don't check for the key, nor do you check the type. That would imply something like an if-statement to ensure the presence of a key, and switching over a type. In such a system, you could forget to check for null, or make some other mistake that causes the program to fail at run time.

The functor approach does not rely on the developer checking anything. It is 100% type safe, enforced by the type system, cannot crash at run time, and does not require you to provide a data type to extract the data into.

That sounds like how you have to access JSON data dynamically in any statically typed language.

But these other languages wouldn't necessarily remain type-safe.

The functor approach doesn't involve any type casting, and null pointer exceptions are impossible.

So, like this sort of thing:

int JsonValue::getAsInt(int defaultIfError);

Or, in Go:

func (JsonValue*) AsInt() (int64, error)

Or are you just talking about it returning the value as a Rust-style Result sum type?