5 ms·

The “Stop at first level of type implementation” is where I see codebases fail at this. The example of “I’ll wrap this int as a struct and call it a UUID” is a

The “Stop at first level of type implementation” is where I see codebases fail at this. The example of “I’ll wrap this int as a struct and call it a UUID” is a really good start and pretty much always start there, but inevitably someone will circumvent the safety. They’ll see a function that takes a UUID and they have an int; so they blindly wrap their int in UUID and move on. There’s nothing stopping that UUID from not being actually universally unique so suddenly code which relies on that assumption breaks. This is where the concept of “Correct by construction” comes in. If any of your code has a precondition that a UUID is actually unique then it should be as hard as possible to make one that isn’t. Be it by constructors throwing exceptions, inits returning Err or whatever the idiom is in your language of choice, the only way someone should be able to get a UUID without that invariant being proven is if they really *really* know what they’re doing. (Sub UUID and the uniqueness invariant for whatever type/invariants you want, it still holds)

munificent 1y ago
> This is where the concept of “Correct by construction” comes in. This is one of the basic features of object-oriented programming that a lot of people tend to overlook these days in their repetitive rants about how horrible OOP is. One of the key things OO gives you is constructors. You can't get an instance of a class without having gone through a constructor that the class itself defines. That gives you a way to bundle up some data and wrap it in a layer of validation that can't be circumvented. If you have an instance of Foo, you have a firm guarantee that the author of Foo was able to ensure the Foo you have is a meaningful one. Of course, writing good constructors is hard because data validation is hard. And there are plenty of classes out there with shitty constructors that let you get your hands on broken objects. But the language itself gives you direct mechanism to do a good job here if you care to take advantage of it. Functional languages can do this too, of course, using some combination of abstract types, the module system, and factory functions as convention. But it's a pattern in those languages where it's a language feature in OO languages. (And as any functional programmer will happily tell you, a design pattern is just a sign of a missing language feature.)
- lock1 1y ago
  I find regular OOP language constructor are too restrictive. You can't return something like Result<CorrectObject,ConstructorError> to handle the error gracefully or return a specific subtype; you need a static factory method to do something more than guaranteed successful construction w/o exception. Does this count as a missing language feature by requiring a "factory pattern" to achieve that?
  - henry700 1y ago
    The natural solution for this is a private constructor with public static factory methods, so that the user can only obtain an instance (or the error result) by calling the factory methods. Constructors need to be constrained to return an instance of the class, otherwise they would just be normal methods. Convention in OOP languages is (un?)fortunately to just throw an exception though.
    - Conscat 1y ago
      In languages with generic types such as C++, you generally need free factory functions rather than static member functions so that type deduction can work.
      - deleted 1y ago
        [deleted]
  - 0x457 1y ago
    This is why constructors are dumb IMO and rust way is the right way. Nothing stops you from returning Result<CorrectObject,ConstructorError> in CorrectObject::new(..) function because it's just a regular function struct field visibility takes are if you not being able to construct incorrect CorrectObject.
  - Jensson 1y ago
    > You can't return something like Result<CorrectObject,ConstructorError> to handle the error gracefully Throwing an error is doing exactly that though, its exactly the same thing in theory. What you are asking for is just more syntactic sugar around error handling, otherwise all of that already exists in most languages. If you are talking about performance that can easily be optimized at compile time for those short throw catch syntactic sugar blocks. Java even forces you to handle those errors in code, so don't say that these are silent there is no reason they need to be.

munificent 1y ago

> This is where the concept of “Correct by construction” comes in. This is one of the basic features of object-oriented programming that a lot of people tend to overlook these days in their repetitive rants about how horrible OOP is. One of the key things OO gives you is constructors. You can't get an instance of a class without having gone through a constructor that the class itself defines. That gives you a way to bundle up some data and wrap it in a layer of validation that can't be circumvented. If you have an instance of Foo, you have a firm guarantee that the author of Foo was able to ensure the Foo you have is a meaningful one. Of course, writing good constructors is hard because data validation is hard. And there are plenty of classes out there with shitty constructors that let you get your hands on broken objects. But the language itself gives you direct mechanism to do a good job here if you care to take advantage of it. Functional languages can do this too, of course, using some combination of abstract types, the module system, and factory functions as convention. But it's a pattern in those languages where it's a language feature in OO languages. (And as any functional programmer will happily tell you, a design pattern is just a sign of a missing language feature.)

lock1 1y ago
I find regular OOP language constructor are too restrictive. You can't return something like Result<CorrectObject,ConstructorError> to handle the error gracefully or return a specific subtype; you need a static factory method to do something more than guaranteed successful construction w/o exception. Does this count as a missing language feature by requiring a "factory pattern" to achieve that?
- henry700 1y ago
  The natural solution for this is a private constructor with public static factory methods, so that the user can only obtain an instance (or the error result) by calling the factory methods. Constructors need to be constrained to return an instance of the class, otherwise they would just be normal methods. Convention in OOP languages is (un?)fortunately to just throw an exception though.
  - Conscat 1y ago
    In languages with generic types such as C++, you generally need free factory functions rather than static member functions so that type deduction can work.
    - deleted 1y ago
      [deleted]
- 0x457 1y ago
  This is why constructors are dumb IMO and rust way is the right way. Nothing stops you from returning Result<CorrectObject,ConstructorError> in CorrectObject::new(..) function because it's just a regular function struct field visibility takes are if you not being able to construct incorrect CorrectObject.
- Jensson 1y ago
  > You can't return something like Result<CorrectObject,ConstructorError> to handle the error gracefully Throwing an error is doing exactly that though, its exactly the same thing in theory. What you are asking for is just more syntactic sugar around error handling, otherwise all of that already exists in most languages. If you are talking about performance that can easily be optimized at compile time for those short throw catch syntactic sugar blocks. Java even forces you to handle those errors in code, so don't say that these are silent there is no reason they need to be.