4 ms·

I see that I have been mistaken in my claim that there is no objective definition of what type safety means. I read the Wikipedia article after reading your pre

I see that I have been mistaken in my claim that there is no objective definition of what type safety means. I read the Wikipedia article after reading your previous comment, because I think I finally understood what you meant. I was convinced that type safe was a different way of saying strongly typed, but now I see that they are not the same thing. Having now read various definitions of type safety, I still do not agree with your initial statement that type safe languages automatically precludes violations of the LSP. The Rectangle > Square problem does not happen because the programmer is not able to specify the necessary type constraints, but because she chooses not to. If by Rectangle one really means "A Rectangle which can mutate its width and height independently" and that can be encoded as a type then yes, a type safe language will enforce the LSP in this instance. But the requirement that a Rectangle has this particular behavior is not something that most programmers would think to enforce with a type, even if their language allowed it. When we model the world, we usually strive to only include what we consider to be essential, and the requirement that width and height should be independently adjustable would not be one many programmers would think essential to what is a Rectangle. But that one's model of a Rectangle has this particular feature is something that is easy to take for granted, and come to rely on once it is there. I.e. a model of a Rectangle is more useful with this feature, but without it, it is still a Rectangle. The problem is not the types. The errors you get when you violate LSP are not type errors, but logic errors.

catnaroek 10y ago
> The Rectangle > Square problem does not happen because the programmer is not able to specify the necessary type constraints, but because she chooses not to. The rectangle-square problem arises because there's no such thing as a type of rectangles in Go to begin with. Rectangles are mathematical objects, and mathematical objects don't mutate or have a physical identity in computer memory. If you change the width or the height of a rectangle, what you get is a different rectangle. > The problem is not the types. The errors you get when you violate LSP are not type errors, but logic errors. Types and logic are two different ways to look at essentially the same thing: https://existentialtype.wordpress.com/2011/03/27/the-holy-trinity/ https://existentialtype.wordpress.com/2011/03/27/the-holy-tr...
- adamlett 10y ago
  The rectangle-square problem arises because there's no such thing as a type of rectangles in Go to begin with. You are aware that Go and a lot of other languages allow the programmer to create new types, right? Rectangles are mathematical objects, and mathematical objects don't mutate or have a physical identity in computer memory Well, I would quibble with your assertion as to what mathematical objective do and don't do. Mathematical objects – like computer models – have whichever properties we assign to them, if that makes them useful. I agree that immutability is one way to ensure that LSP is not violated. And I also agree that a Rectangle is probably best modeled as an immutable value object. But LSP doesn't actually talk about Rectangles and Squares, that just happens to be the example everyone always uses to illustrate it. Types and logic are two different ways to look at essentially the same thing Perhaps I should have used the term modeling error instead. My point was that types can't save you from modeling the domain wrongly. The type system can't save you from using Floating Point numbers to model money for instance.
  - catnaroek 10y ago
    > You are aware that Go and a lot of other languages allow the programmer to create new types, right? Yes. But they don't let you create a type whose inhabitants are rectangles: https://news.ycombinator.com/item?id=12233268 https://news.ycombinator.com/item?id=12233268 > Mathematical objects – like computer models – have whichever properties we assign to them, if that makes them useful. Sure. You can invent your own mathematical object that's kinda like a rectangle, but can mutate. As long as you don't call it “rectangle”, there will be no confusion. > I agree that immutability is one way to ensure that LSP is not violated. Immutability isn't enough to solve the rectangle-square problem. For instance, Standard ML has immutable values (as well as mutable objects), but it doesn't solve the 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. And the LSP is never violated, because it's a tautology. It just buys you less than you think in most languages. > And I also agree that a Rectangle is probably best modeled as an immutable value object. The notion of a “value object” is still problematic. A “value object” still has a physical identity in computer memory. What you need to do is ditch the object and work with the value itself. > My point was that types can't save you from modeling the domain wrongly. The type system can't save you from using Floating Point numbers to model money for instance. Of course. But I never said that types automatically make your models correct. What I said is that you need appropriate type structure to model your problem domain correctly. It's a necessary but not sufficient condition.

catnaroek 10y ago

> The Rectangle > Square problem does not happen because the programmer is not able to specify the necessary type constraints, but because she chooses not to. The rectangle-square problem arises because there's no such thing as a type of rectangles in Go to begin with. Rectangles are mathematical objects, and mathematical objects don't mutate or have a physical identity in computer memory. If you change the width or the height of a rectangle, what you get is a different rectangle. > The problem is not the types. The errors you get when you violate LSP are not type errors, but logic errors. Types and logic are two different ways to look at essentially the same thing: https://existentialtype.wordpress.com/2011/03/27/the-holy-trinity/ https://existentialtype.wordpress.com/2011/03/27/the-holy-tr...

adamlett 10y ago
The rectangle-square problem arises because there's no such thing as a type of rectangles in Go to begin with. You are aware that Go and a lot of other languages allow the programmer to create new types, right? Rectangles are mathematical objects, and mathematical objects don't mutate or have a physical identity in computer memory Well, I would quibble with your assertion as to what mathematical objective do and don't do. Mathematical objects – like computer models – have whichever properties we assign to them, if that makes them useful. I agree that immutability is one way to ensure that LSP is not violated. And I also agree that a Rectangle is probably best modeled as an immutable value object. But LSP doesn't actually talk about Rectangles and Squares, that just happens to be the example everyone always uses to illustrate it. Types and logic are two different ways to look at essentially the same thing Perhaps I should have used the term modeling error instead. My point was that types can't save you from modeling the domain wrongly. The type system can't save you from using Floating Point numbers to model money for instance.
- catnaroek 10y ago
  > You are aware that Go and a lot of other languages allow the programmer to create new types, right? Yes. But they don't let you create a type whose inhabitants are rectangles: https://news.ycombinator.com/item?id=12233268 https://news.ycombinator.com/item?id=12233268 > Mathematical objects – like computer models – have whichever properties we assign to them, if that makes them useful. Sure. You can invent your own mathematical object that's kinda like a rectangle, but can mutate. As long as you don't call it “rectangle”, there will be no confusion. > I agree that immutability is one way to ensure that LSP is not violated. Immutability isn't enough to solve the rectangle-square problem. For instance, Standard ML has immutable values (as well as mutable objects), but it doesn't solve the 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. And the LSP is never violated, because it's a tautology. It just buys you less than you think in most languages. > And I also agree that a Rectangle is probably best modeled as an immutable value object. The notion of a “value object” is still problematic. A “value object” still has a physical identity in computer memory. What you need to do is ditch the object and work with the value itself. > My point was that types can't save you from modeling the domain wrongly. The type system can't save you from using Floating Point numbers to model money for instance. Of course. But I never said that types automatically make your models correct. What I said is that you need appropriate type structure to model your problem domain correctly. It's a necessary but not sufficient condition.