Default extent considered harmful

[pavel.kirienko]

@pavel.kirienko

@scottdixon

I’d rather make @sealed the default since this also gets rid of the default extent formula and makes naive implementations or prototyping with UAVCAN more immediate and successful. It seems like any datatype author would start with a prototype and only need to think about the future when finalizing a design. It’s in this later phase of a project that one would take the time to calculate extents properly.

I think your assumption that a developer would sit down and think about the future is unsound. My experience indicates that people rarely do that, so we should either force them to (make @extent required) or do it for them (default extent plus the tooling approach).

The image of an innocent developer who suddenly realized that a sealed data type that’s been deployed in a gazillion units needs updating haunts me by day and night.

1. Nobody Reads the Manual
2. You Can’t Force People to do the Right Thing

This is true but surely we can force people to read the manual. Would it be an acceptable solution if we made it necessary to specify either @sealed or @extent <...>? My assumption here that the time it takes to type @-s-e-a-l-e-d is enough to question why are you doing it and what are the implications.

It does raise the entry barrier a notch, but then again, maybe it should. Maybe the developer should be forced to think about the future. Maybe we should also instill a bit of existential crisis for good measure.