2 ms·
> this happens because the rules enforcement can only happen effectively if the rules themselves are perfect and complete and that gets harder to guarantee with
by photonthug 3y ago
> this happens because the rules enforcement can only happen effectively if the rules themselves are perfect and complete and that gets harder to guarantee with scale and speed of iteration.
IMHO, project-level assertions about initialization-order feels a little bit dirty, but potentially practical as long as there's only a few rules. Surely even a bazillion line monolith can still often be thought of in terms of a few layers. But by the time you get to lots of rules it's getting hard to stomach the code-smell and keep justifying it as practical. At that point I'd want something dynamic and backed by a real solver.. not just a layer of static-analysis.
The deal framework for DBC doesn't quite do this afaik but is starting to expose some stuff along these lines, and at least can assert imports are "pure". https://deal.readthedocs.io/details/module_load.html https://deal.readthedocs.io/details/module_load.html
- ianandrich 3y agoHave you had any experience using deal on personal projects or professionally yet?
- photonthug 3y agoSo far I'm working it into personal projects gradually. Runtime checks are at least as useful as something like pydantic's validation, and more expressive, because validation is basically "pre" but now deal can provide the "post". DBC via pre/post might be "just" syntactic sugar on asserts, but notation matters: it looks great, it reduces cognitive load. It easily does stuff that's impossible or just awkward with types, so having an alternate way to express constraints available probably keeps me out of certain rabbit holes. Really looking forward to trying verification ( https://deal.readthedocs.io/basic/verification.html https://deal.readthedocs.io/basic/verification.html ) but I think I need to hit some critical mass of annotation first.