On Monday, 12 October 2015 at 07:39:30 UTC, Kagamin wrote:
On Thursday, 8 October 2015 at 14:05:07 UTC, Jonathan M Davis
wrote:
Maybe, but having classes be value generally makes no sense,
because you can't use polymorphism with value types.
If it doesn't make sense for reference types to be value types,
then your suggestion to use structs (value types) to implement
reference types doesn't make sense either.
My point is that without a level of indirection, polymorphism
isn't involved. For polymorphism, you have a pointer or a
reference of a base type, and it points/refers to an object of a
derived type which then implements some of the functionality
differently from the base. If you have a value type, there is no
polymorphism, because there is no indirection. You're dealing
with the exact type that the variable is. With a value type, all
inheritance does is provide a way to reuse code (and not even a
very good way to reuse code, since you can only derive from one
type at a time). Inheritance's primary benefit is with
polymorphism. Given that, it makes a lot of sense to use
inheritance with objects on the heap and a lot less sense to use
it for objects on the stack.
You can stick value types on the heap and pass around pointers or
references to them, but then you're not dealing with
polymorphism. You're just providing a way to have multiple pieces
of code point operate on the same object, whereas passing it
around on the stack means copying it. In some cases, ref would do
the job just as well. But I wasn't really trying to say anything
about whether value types made sense on the heap or anything like
that. My point was entirely about polymorphism not applying to
anything without using a pointer or reference.
- Jonathan M Davis
