3 ms·

The problem with a struct-like construct is that it doesn't have any way of guaranteeing some data is present and valid or not. I'm thinking about C++-like stru

The problem with a struct-like construct is that it doesn't have any way of guaranteeing some data is present and valid or not. I'm thinking about C++-like structs or python maps. An object representing a dumb data structure can be written in order to have many useful guarantees upon construction, for example making it impossible for the object to be created without fully initializing it, or guaranteeing the presence of all "keys" in the structure. This is easily guaranteed statically and it's so damn useful!

ninkendo 9y ago
I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the object, capable of handling any of the values expressible by the object's type. That is, you need useful zero values (which means no null pointers), and any method that takes the object should be able to do sensible (if not useful) things even if things are their zero-values. As for validation, you don't always know what different consumers of your type consider to be valid or not. For a rectangle any non-negative size should be valid, for instance, but when you try to pass a zero-sized x side to a class that (for some reason) needs non-zero x length, that class should be doing the validation, not the Rectangle class itself. I think I'm coming at this after doing nothing but golang for a few years, and then having to switch to Java recently, and I really hate the language so far, mostly because of the style of programming it encourages.
- spdionis 9y ago
  I mostly agree with you except: > that class should be doing the validation, not the Rectangle class itself. I partially disagree. You should have a layer after which all (request) parameters are surely and clearly validated. This avoids repeated validations. This layer should be separated from any logic layer. Additionally a class like Rectangle should have a sanity check in the constructor, and throw a fatal exception if the passed in values are invalid. > you don't always know what different consumers of your type consider to be valid or not I try to make things in such a way that an object of a type is either valid or not. If two consumer have different notions of validity about the ~~same~~ similar (!) type of data, I'd rather create a new type. EDIT: For the exact reason that this allows to use static analysis and avoid silly checks for 0-sized x sides. What does a 0-sized side mean? This type of data can only come from bad user-input, and it should stop at the first line of the controller, and not a step further.

ninkendo 9y ago

I appreciate what you're saying, and I agree that it's a valid approach, but I would be more interested in making any of the methods which are interested in the object, capable of handling any of the values expressible by the object's type. That is, you need useful zero values (which means no null pointers), and any method that takes the object should be able to do sensible (if not useful) things even if things are their zero-values. As for validation, you don't always know what different consumers of your type consider to be valid or not. For a rectangle any non-negative size should be valid, for instance, but when you try to pass a zero-sized x side to a class that (for some reason) needs non-zero x length, that class should be doing the validation, not the Rectangle class itself. I think I'm coming at this after doing nothing but golang for a few years, and then having to switch to Java recently, and I really hate the language so far, mostly because of the style of programming it encourages.

spdionis 9y ago
I mostly agree with you except: > that class should be doing the validation, not the Rectangle class itself. I partially disagree. You should have a layer after which all (request) parameters are surely and clearly validated. This avoids repeated validations. This layer should be separated from any logic layer. Additionally a class like Rectangle should have a sanity check in the constructor, and throw a fatal exception if the passed in values are invalid. > you don't always know what different consumers of your type consider to be valid or not I try to make things in such a way that an object of a type is either valid or not. If two consumer have different notions of validity about the ~~same~~ similar (!) type of data, I'd rather create a new type. EDIT: For the exact reason that this allows to use static analysis and avoid silly checks for 0-sized x sides. What does a 0-sized side mean? This type of data can only come from bad user-input, and it should stop at the first line of the controller, and not a step further.