logoalt Hacker News

In Praise of Exhaustive Destructuring

37 pointsby avandecremelast Sunday at 8:58 AM7 commentsview on HN

Comments

sarrephtoday at 12:04 PM

I used to be a die-hard destructurer! I liked the readability aspect, but ultimately two core problems emerged that pushed me towards dot-accessors:

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.

show 1 reply
healthworkertoday at 7:36 AM

The dangerous weather example seems like a poor example. Most fields I would add would be orthogonal to existing functionality, and if they weren't, I would account for things I need to change (e.g. the is dangerous function) during the specification phase.

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.
     */
show 1 reply
draw_downtoday at 1:21 PM

[dead]