1. It's highly verbose, especially in a language like TypeScript where you're often defining properties in types and then destructuring the same properties, making the whole thing look quite duplicative.

2. If you're passing an object through different functions doing similar things, I would quite often have to rename a destructured property in TypeScript because I would want to reuse the same name in a function-scoped variable.

I think for exhaustive switches, destructuring can be fine, but in general as long as you've got a well-defined set of types backing everything up, dot-access is neater.

--

Also on the point about optional parameters:

> let's suppose some stations now have an anemometer and are able to record wind speed

I find that discriminated unions are so much better at dealing with these kinds of problems. Also tends to work better with dot-access because you're not then destructuring undefined properties.

As an example of what I mean: The spec for "is dangerous" would have specified what "dangerous" means, and if that included high speeds, then that would have been known in advance when I made a plan to implement the speed feature.

The reason I mention this is that agentic coding seems to be requiring us to move to "spec-driven development" and it behooves us all to learn how best to adapt to this new landscape.

A simple example of an inline spec (i.e., a spec living as a comment in the code file, a bit like literate programming) for "is dangerous" would be something like:

    /*
     * dangerous = anything that would cause a risk of getting hurt for a healthy adult, e.g. heat stroke, lightning strike, hypothermia, gale force wind, flood, hurricane, tsunami, earthquake
     * Not all of this is implemented now, but that is what this function should try to do.
     */