this post was submitted on 03 Mar 2024
29 points (100.0% liked)
Programming
423 readers
9 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Wouldn't static type checking solve most of these issues?
I think you are right. I did not consider this. Will try that next!
What language are you writing that you didn't even think of this?
Typescript, but that's not the issue. You probably have to leverage types in a specific way to get all the protections I am talking about. For example, I want it such that if a new field is added to a type, every user of the type must explicitly either use it or explicitly declare that it won't. From my experience with type systems, you typically aren't required to explicitly declare that you won't use a field in a dictionary / record type.
Ok, TIL there's a thing called Required, but otherwise, one way to do this is to rename the other part/field/key(s), so that old code reveals itself in much the same way as using a deleted field (because it does, actually)
Another way is explicitly have a separate type for records with/without the feature. (if one is a strict subset, you can have a downgrade/slice method on the more capable class.
Lastly, I would say that you need static typing, testing, both. People from static-land get vertigo without types, and it does give good night sleep, but it's no substitute for testing. Testing can be a substitute for static typing in combination with coverage requirements, but at that point you're doing so much more work that the static typing straight jacket seems pretty chill.
A simple but hackish solution is to version your types. New field? Foo becomes Foo2! Now nothing builds and you're sure you'll have to go over every usage of the type.
Add a second commit to revert to Foo, and there you go. Of course you'd need two reviews but the second one is trivial
What? How does someone declare that they won't use a type? What does that even mean?
Do you have an example use case that you're trying to solve? What additional type are you adding that would break existing users usage? If that's the case, maybe use an entirely different type, or change the class name or something
I gave an example use case in the main post, but I'll summarize it again here:
Suppose we have a to-do task manager. A task is an important entity that will be used in many parts of our codebase.
Suppose we add a new field to this task entity. For example, let's say we now added a priority field in our task that previously didn't exist, so users can define if a task is high priority.
The problem: this task entity is being used in many parts or our codebase. How do we make sure that every one of those parts that needs to use the new field does use it? How do we make sure we don't miss any?
I hope this makes sense. If it doesn't, feel free to ask any questions.
Have you considered the
Required
generic?https://www.typescriptlang.org/docs/handbook/utility-types.html#requiredtype
Thanks for the tip! I think that is indeed what I need. Thank you :)
Oh are you talking about creating the object? Yeah I think you might get better answers in a TS thread, because that question and the response here makes no sense in most statically typed languages.
If there's anything that doesn't make sense in my question, feel free to ask any questions or clarifications on any part of it.
Yeah, in most statically-typed languages this is simply the default behavior unless you specifically declare a field as optional.