4 ms·

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 ho

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

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.