И действительно, почему бы и нет. Это вполне оправдано концептуально.
Sounds slightly insane to me, no offense intended =) Explanations below.
А кто-то чуть выше говорил что-то про "IsA". :-)
Subclassing must be an IsA relationship. But not every IsA relationship should be subclassing =)
The point of my string/substring example is actually the same point that Alex Stepanov made in one of his interviews. The semantics for String#substring clearly demand that the returned object should have the same class as the original. AND we don't want to override the "substring" method in each subclass of String we create. This problem can't be solved without templates or generics of some kind. And it's not just about strings.
About real and complex numbers: you're clearly talking from a mathematician's point of view. I come from a math background myself, but in some cases the programmer's common sense should outweigh the matematician's rigor. Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit, and it really helps readability when you come back to the code some months later.
Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Real and complex numbers are used in different circumstances, with different semantics and by different groups of programmers. They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
One more note about Real and Integer: the OCaml people actually decided to have different arithmetic operators for integers and reals (+. and *. vs + and *), and make all conversions explicit. This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading. Most programmers use integers most of the time, and don't even notice that.
I think this explains my point about IsA relationships and subclassing. Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise. Making Integer a subclass of Real doesn't make anything easier for programmers. I've seen languages where Integer and Real share a common superclass; but I haven't seen one in which they are directly related.
no subject
Sounds slightly insane to me, no offense intended =) Explanations below.
А кто-то чуть выше говорил что-то про "IsA". :-)
Subclassing must be an IsA relationship. But not every IsA relationship should be subclassing =)
The point of my string/substring example is actually the same point that Alex Stepanov made in one of his interviews. The semantics for String#substring clearly demand that the returned object should have the same class as the original. AND we don't want to override the "substring" method in each subclass of String we create. This problem can't be solved without templates or generics of some kind. And it's not just about strings.
About real and complex numbers: you're clearly talking from a mathematician's point of view. I come from a math background myself, but in some cases the programmer's common sense should outweigh the matematician's rigor. Cases when we need a real-to-comlex conversion are rare enough to justify making it explicit, and it really helps readability when you come back to the code some months later.
Besides, Real isn't even intuitively a subclass of Complex, because most people don't use complex numbers in their programs. (Just as users of Integer most often don't care that it's Real.) And what happens when we add Quaternions to the soup? Should they become a superclass to Complex? Surely this is absurd.
Real and complex numbers are used in different circumstances, with different semantics and by different groups of programmers. They should not be related, because it makes life harder for the majority of people who just want reals (or integers, for that matter).
One more note about Real and Integer: the OCaml people actually decided to have different arithmetic operators for integers and reals (+. and *. vs + and *), and make all conversions explicit. This is actually nice, because every possibility of rounding error stands out in the code, and isn't implicit in the operator overloading. Most programmers use integers most of the time, and don't even notice that.
I think this explains my point about IsA relationships and subclassing. Subclassing is a practical tool for programmers to use, not a theorist's pointless exercise. Making Integer a subclass of Real doesn't make anything easier for programmers. I've seen languages where Integer and Real share a common superclass; but I haven't seen one in which they are directly related.