4 ms·

Ellipses have major and minor radii; in circles, both are the same length. This is exactly the issue. According to specialization by constraint when an ellipse

Ellipses have major and minor radii; in circles, both are the same length. This is exactly the issue. According to specialization by constraint when an ellipse has equal radii then it is both an ellipse and a circle, therefore a circle isa ellipse, therefore a circle is a subtype of ellipse. Hence a square isa rectangle. The specialization by constraint argument is that any type system that requires a rectangle to be a subtype of square or both to be subtypes of polygon is inherently broken. LSP says that if a circle is a subtype of ellipse then it can be used in place of an ellipse. But it can't, so a circle can't be a subtype of ellipse. LSP and specialization by constraint are not compatible.

barrkel 17y ago
LSP says that if a circle is a subtype of ellipse then it can be used in place of an ellipse. But it can't You haven't shown that - you've merely asserted it. If you live in a world of immutable ellipses, and you need different behaviour from circles and non-circle ellipses, you can make circles subtypes of ellipses without any problems, and still satisfy LSP - because we're not specializing by constraint. The most important point: circleness is attribute of an ellipse, and if the ellipse is immutable - its radii can't be changed - then that circleness can be contained in the type without problem.
- davidmathers 17y ago
  You haven't shown that I don't understand. An ellipse contains more information than a circle. You can't ask a circle for the length of its minor radius, so how can it substitute for an ellipse? I'm not sure we're speaking the same language.
  - barrkel 17y ago
    I believe you're assuming more things about the programmatic interface of a circle type than is necessarily true. An ellipse with equal major and minor radii is a circle. That much is mathematical fact. Equivalently, a circle is a special kind of ellipse. As an ellipse, you can certainly ask it for major and minor radii. But "more information" is an implementation detail. If Circle were a subclass of AbstractEllipse, which itself also had a concrete Ellipse subclass, Circle might implement both major and minor radii "properties" in terms of a single field. But again, this is just an implementation detail. All this is only practically useful if there's a reason for considering circles as ellipses, or for specializing behaviour for circles. For example, the circumference calculation for circles is much simpler than for ellipses, so we might want to specialize it. Since our values are immutable, there's no problem in capturing this optimization in the type and overriding the appropriate method. (I'm assuming immutable values throughout, to make it clear.)
    - davidmathers 17y ago
      You seem to be saying that circles are not subtypes of ellipses. That circleness is just a property of ellipses. If we accept that then the whole issue is moot, and substitutability is true by tautology. A circle is a triple: (x,y,radius). An ellipse is a 5-tuple: (x,y,major,minor,angle). Maybe we should be talking about angle instead? It can't be derived from a circle. What happens when you feed a circle to selectEllipsesByAngle()?
      - barrkel 17y ago
        If isEllipseAtAngle(someAngle): boolean were a method, a Circle type could return true for every angle.

barrkel 17y ago

LSP says that if a circle is a subtype of ellipse then it can be used in place of an ellipse. But it can't You haven't shown that - you've merely asserted it. If you live in a world of immutable ellipses, and you need different behaviour from circles and non-circle ellipses, you can make circles subtypes of ellipses without any problems, and still satisfy LSP - because we're not specializing by constraint. The most important point: circleness is attribute of an ellipse, and if the ellipse is immutable - its radii can't be changed - then that circleness can be contained in the type without problem.

davidmathers 17y ago
You haven't shown that I don't understand. An ellipse contains more information than a circle. You can't ask a circle for the length of its minor radius, so how can it substitute for an ellipse? I'm not sure we're speaking the same language.
- barrkel 17y ago
  I believe you're assuming more things about the programmatic interface of a circle type than is necessarily true. An ellipse with equal major and minor radii is a circle. That much is mathematical fact. Equivalently, a circle is a special kind of ellipse. As an ellipse, you can certainly ask it for major and minor radii. But "more information" is an implementation detail. If Circle were a subclass of AbstractEllipse, which itself also had a concrete Ellipse subclass, Circle might implement both major and minor radii "properties" in terms of a single field. But again, this is just an implementation detail. All this is only practically useful if there's a reason for considering circles as ellipses, or for specializing behaviour for circles. For example, the circumference calculation for circles is much simpler than for ellipses, so we might want to specialize it. Since our values are immutable, there's no problem in capturing this optimization in the type and overriding the appropriate method. (I'm assuming immutable values throughout, to make it clear.)
  - davidmathers 17y ago
    You seem to be saying that circles are not subtypes of ellipses. That circleness is just a property of ellipses. If we accept that then the whole issue is moot, and substitutability is true by tautology. A circle is a triple: (x,y,radius). An ellipse is a 5-tuple: (x,y,major,minor,angle). Maybe we should be talking about angle instead? It can't be derived from a circle. What happens when you feed a circle to selectEllipsesByAngle()?
    - barrkel 17y ago
      If isEllipseAtAngle(someAngle): boolean were a method, a Circle type could return true for every angle.