4 ms·

Yes. But they don't let you create a type whose inhabitants are rectangles. I have no idea you mean by that. The link you provided did not help. Immutability

Yes. But they don't let you create a type whose inhabitants are rectangles. I have no idea you mean by that. The link you provided did not help. Immutability isn't enough. I'm sceptical about that. I am going to need an example of a LSP violations made with immutable types. For instance, Standard ML has immutable values (as well as mutable objects), but it doesn't solve the rectangle-square problem because the core language doesn't have subtypes to begin with. Solving the problem requires refinement types, so that squares can be defined as a refinement over rectangles. I'm not sure what you are saying here. Does ML prevent the problem, or doesn't it? You seem to be saying that it doesn't. But according to Wikipedia, ML is type safe (for some definition of that term), and in your initial comment, you stated that type safe languages ensure adherence to LSP. The notion of a “value object” is still problematic. A “value object” still has a physical identity in computer memory. Because I can get the address of it in Go? So what? That's hardly something you do by accident. And if your point is about what the language makes possible, rather than what it makes likely, I assure you that you can get in wrong in any language. The only difference is how much effort it requires. I never said that types automatically make your models correct You pretty much did with your initial comment that type safe languages prevent violations of LSP. you need appropriate type structure to model your problem domain correctly No, simply not true. You can model your domain correctly in any Turing-complete language. Types may make it easier, especially as your programs grow more complex, but types can't help you choose the correct way to model your domain. LSP is not about type errors: The symptoms of violating it are not that operations are performed on values that are not appropriate for values of that type. In the Rectangle/Square example, calling setWidth() or setHeight() on a Square are perfectly alright as far as the Type system is concerned. The problem is simply that the resulting behaviour of the program probably not what the programmer intended. If the programmer had thought to specify -- using types -- that a Rectangle’s width and height should always be independently adjustable, then it's probably a fair assumptions that the same programmer would not have accidentally made a subtype of Rectangle that violated this invariant to begin with.

catnaroek 10y ago
> I have no idea you mean by that. The link you provided did not help. You can't define a type in Go whose instances are rectangles. If you define: type Rectangle struct { Width, Height int } Then a so-called “Rectangle” is actually a mutable object whose current state is one rectangle, but whose state the very next moment might be another rectangle. > I'm sceptical about that. I am going to need an example of a LSP violations made with immutable types. I never said that ML violates the LSP. I said that it doesn't solve the rectangle-square problem. > I'm not sure what you are saying here. Does ML prevent the problem, or doesn't it? You seem to be saying that it doesn't. But according to Wikipedia, ML is type safe (for some definition of that term), and in your initial comment, you stated that type safe languages ensure adherence to LSP. ML adheres to the LSP trivially, because the language has no subtyping relation to begin with. Another way to view this is that every type has exactly one subtype: the type itself. Unfortunately, precisely because of this, it doesn't solve the rectangle-square problem. > Because I can get the address of it in Go? So what? That's hardly something you do by accident. And if your point is about what the language makes possible, rather than what it makes likely, I can't prove theorems about what a language makes “likely”. > I assure you that you can get in wrong in any language. The only difference is how much effort it requires. You can't take the address of a rectangle in ML. The only things that have physical identities are reference cells, and two physically distinct reference cells are always considered different values, even if their contents are the same. > In the Rectangle/Square example, calling setWidth() or setHeight() on a Square are perfectly alright as far as the Type system is concerned. What you're calling a “Square” is, as a matter of fact, not a square. > LSP is not about type errors: The symptoms of violating it are not that operations are performed on values that are not appropriate for values of that type. You are projecting your wants and desires (namely: a type of rectangles, a type of squares, and that the latter be a subtype of the former) onto the LSP, but the LSP doesn't care. The LSP only cares about the types the language actually gives you. The meaning of a type isn't in its name, but in what its instances actually do. > If the programmer had thought to specify -- using types -- that a Rectangle’s width and height should always be independently adjustable, Then the programmer doesn't know what a rectangle is. (Assuming you meant “adjustable using a setter”.)

catnaroek 10y ago

> I have no idea you mean by that. The link you provided did not help. You can't define a type in Go whose instances are rectangles. If you define: type Rectangle struct { Width, Height int } Then a so-called “Rectangle” is actually a mutable object whose current state is one rectangle, but whose state the very next moment might be another rectangle. > I'm sceptical about that. I am going to need an example of a LSP violations made with immutable types. I never said that ML violates the LSP. I said that it doesn't solve the rectangle-square problem. > I'm not sure what you are saying here. Does ML prevent the problem, or doesn't it? You seem to be saying that it doesn't. But according to Wikipedia, ML is type safe (for some definition of that term), and in your initial comment, you stated that type safe languages ensure adherence to LSP. ML adheres to the LSP trivially, because the language has no subtyping relation to begin with. Another way to view this is that every type has exactly one subtype: the type itself. Unfortunately, precisely because of this, it doesn't solve the rectangle-square problem. > Because I can get the address of it in Go? So what? That's hardly something you do by accident. And if your point is about what the language makes possible, rather than what it makes likely, I can't prove theorems about what a language makes “likely”. > I assure you that you can get in wrong in any language. The only difference is how much effort it requires. You can't take the address of a rectangle in ML. The only things that have physical identities are reference cells, and two physically distinct reference cells are always considered different values, even if their contents are the same. > In the Rectangle/Square example, calling setWidth() or setHeight() on a Square are perfectly alright as far as the Type system is concerned. What you're calling a “Square” is, as a matter of fact, not a square. > LSP is not about type errors: The symptoms of violating it are not that operations are performed on values that are not appropriate for values of that type. You are projecting your wants and desires (namely: a type of rectangles, a type of squares, and that the latter be a subtype of the former) onto the LSP, but the LSP doesn't care. The LSP only cares about the types the language actually gives you. The meaning of a type isn't in its name, but in what its instances actually do. > If the programmer had thought to specify -- using types -- that a Rectangle’s width and height should always be independently adjustable, Then the programmer doesn't know what a rectangle is. (Assuming you meant “adjustable using a setter”.)