Re: value type pardox
* Nilone:
On Oct 24, 6:24 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* SG:
On 24 Okt., 14:06, Nilone <rea...@gmail.com> wrote:
Classes and objects are somewhat more complex. A specific class may
define a value type, if the objects it defines are immutable and
comparable for equality.
I don't think so. In imparative languages ("object model", every
"variable" is located somewhere in memory, some of them can be
changed) we refer to int, double, etc as value types. I can create an
int variable ("object") and assign different values to it. I would
call this "mutation". I can certainly create a class called point2d
which contains two doubles as direct members. A non-const point2d
object which can be mutated can still be a "value type" as far as I'm
concerned.
Immutability comes into the picture when indirection is used to
implement value types. Take java.lang.String for example. The
variables we deal with here are actually "handles" or "references" and
can always be mutated. But they refer to immutable objects whose state
is a representation of a value and can be shared among different
objects of this value type. This is however not restricted to
languages like Java and C#. You could do this in C++ as well (ignoring
reference counting w.r.t. immutability).
I think that may be what Nilone referred to, without quite understanding it?
There's so much crap spewed out in this thread, sorry.
I believe I understand the concepts reasonably well, and would advise
some tact and civility if you wish to engage in serious discussion.
I wasn't talking about you.
But anyway, it's better to call a spade a spade than go beating about bush. :-)
This obsession with being tactful and civil is how misconceptions are allowed to
propagate, it's downright dangerous and very counter-productive, pretending that
there isn't something Seriously Wrong but just a SubOptimal Point of View.
For example, the notion of a type as a set of values is a mathematical type
notion, not one suitable for imperative programming. E.g. an interface type or
an incomplete type doesn't match this concept (mathematically they'd all be the
same type, the type of an empty set of values).
The values of an interface type is not an empty set, but all possible
objects which implement that interface. The same applies to an
incomplete type.
Consider incomplete types that are never completed.
We use them all the time in C++. 'void' is but one example. Doing e.g.
typedef Box<int, struct IntBoxIdType> IntBox;
where IntBoxIdType is never completed anywhere, is another example.
There are no values of those types.
Being defined by their value sets they would therefore be equivalent.
But the whole point is that they're distinct.
Stefan Ram already corrected my definition of a type as a set to one
defined by operators, which apply directly to imperative programming.
I still assert the same relationship between type, value and variable.
It's just silly: it does not map to reality. Or more plainly, not beating about
the bush, it's idiocy and pure fantasy, a child's simpleton view. In reality,
especially in C++ programming, we have lots of types without any possible values
whatsoever.
More seriously, mapping e.g.
'integer' as a subtype of 'real' doesn't work in programming, and generally the
subset relationship for values goes the Other Way in programming compared to
mathematical types. The root cause has to do with math dealing with unchanging
values and inferring types from value properties, value sets constraining the
possible types one may assign, while programming deals with changing variables
and have types constraining value properties, which also is the Other Way.
I'm aware of the concepts of covariance and contravariance.
Yes, but that's not what's involved here.
Consider the C++ types
struct Animal {};
struct Dog: Animal { int tailSize; };
The set of Dog values is a subset of the set of Animal values, since every Dog
value is an Animal value.
Consider then the types
struct RationalNumber{ int q, d; };
struct Integer: RationalNumber {};
The set of Integer values is a subset of the set of RationalNumber values, in
the same way as of for Animal and Dog, but there's something seriously wrong
with /this/ class derivation -- can you see what it is? :-)
That is, although the mathematical type concept makes integers a subtype of
rational numbers, because every integer is rational number, it's just not so in
programming. And I explained the causes in the quoted text above. However, it
might be more clear and understandable with this little concrete example.
I believe
the problems you're referring to occurs when the concepts of type,
value and variable are confused, which is why I used those terms
carefully in my post.
Yes, the usual mathematically-oriented definitions of type suffer from such
confusion.
So this attempt at formalizing types via mathematics is just utterly misguided.
It is basically the common fallacy of reasoning by analogy, thinking that if
limited model A correctly describes some features of a more rich system B (an
analogy) then A defines B and can be used to draw all kinds of conclusions about
B. The reality is the other way around, if there is any such connection...
It's very common though, a very common error in textbooks, and I think it's even
there in Wikipedia (I don't care to check).
Cheers & hth.,
- Alf
I recommend the works of Alan Kay, Luca Cardelli, Chris Date, Alistair
Cockburn and Terry Halpin, among others.
No, just start and end with Liskov. ;-)
Cheers & hth.,
- Alf