value type pardox

[bobby]

Hello group,

what is a value type in C++ or Java or C#? Is it a class or an object?
I can see one can call a method(For instance ToString()) on an Int16
and so on;So is it an object?At the same time we use Int16 to
instantiate a variable Int16 a =new Int16();So is it a class?

can clarify this for me?Class or Object

Thanks
B.

 

[Stefan Ram]

what is a value type

Let »v« be a function from the type T into a set S. (This is
not a function nor a set in the sense of C++, but a function
and set in the sense of mathematics, so there does not have
to be a definition of v or S in C++ code.)

Let x be an r-value of the type T.

We call v(x) the »v value of x«.

Iff the result and behavior of any expression¹ with
subexpression of the value type depends only on the v value
of this subexpression, then T is a value type with regard to v.

For example, x == y (in C++ code) iff v(x) is v(y) (in our
set S outside of C++ code).

1) Except for some special cases, such as »&x«.

(This definition was just invented by me according to my
personal interpretation of this notion.)

 

[Joshua Maurice]

Hello group,

what is a value type in C++ or Java or C#? Is it a class or an object?
I can see one can call a method(For instance ToString()) on an Int16
and so on;So is it an object?At the same time we use Int16 to
instantiate a variable Int16 a =new Int16();So is it a class?

can clarify this for me?Class or Object

A class is a type. An object is a value. An object or value is an
instance of a type.

For example, "int" is a type. Types have a set of values. The type
"int" has a set of values
INT_MIN, INT_MIN + 1, ..., -1, 0, 1, ..., INT_MAX - 1, INT_MAX
The type "int" is a value type. It has value semantics. Ex:
int x = 1;
int y = x;
x = 2;
assert(y == 1);
Changing x does not change y. This is because the type "int" has value
semantics aka copy semantics; it is a value type.

Ex:
int x = 1;
int& y = x;
x = 2;
assert(y == 2);
Changing x does change y. This is because the type "int&" (read:
reference to int, or int reference) has reference semantics. "int&" is
not a value type.

Classes are types. Objects and values are instances of classes. A
value type is a type, but a type is not necessarily a value type.

At least, that's my understanding of the terms involved. At the very
least, there should be no confusion over "is it a class or an object".
A class, aka type, is very different than an object, aka value, aka
instance of a type.

Note that some programming languages take these general concepts and
restrict and redefine these terms. Neither definition is wrong (though
damn confusing and annoying). It's just that there are several
definitions. Which is in use depends on context.

However, this classification is very C++ centric. There exist other
programming languages where types are mutable and usable in
expressions. That is, a type is also a value. For example, in Java,
"Integer" is a type. You can have "Integer" objects. There is also an
"Integer" object, an instance of the type "Class". There is also a
"Class" object, itself an instance of the type "Class". (At least, I
think. I'm not the most clear on the Java specifics.)

PS: Stefan Ram, you should really stop setting the "do not archive"
flag. It's most annoying to anyone using google groups, as the
discussion will become unreadable in a week.

 

[Joshua Maurice]

Hello group,

what is a value type in C++ or Java or C#? Is it a class or an object?
I can see one can call a method(For instance ToString()) on an Int16
and so on;So is it an object?At the same time we use Int16 to
instantiate a variable Int16 a =new Int16();So is it a class?

can clarify this for me?Class or Object

A class is a type. An object is a value. An object or value is an
instance of a type. [...]
Classes are types. Objects and values are instances of classes. A
value type is a type, but a type is not necessarily a value type.

Meh, to be slightly more specific and clear: Types have a set of
values. An object is a thingy, a variable, which at any particular
time holds / is / contains a single value of its type. Over the course
of the program, if the object and type are mutable (aka changeable,
not the C++ keyword mutable), then the object can take on different
values through explicit mutation, like assignment.

 

[Saeed Amrollahi]

Hello group,

what is a value type in C++ or Java or C#? Is it a class or an object?
I can see one can call a method(For instance ToString()) on an Int16
and so on;So is it an object?At the same time we use Int16 to
instantiate a variable Int16 a =new Int16();So is it a class?

can clarify this for me?Class or Object

Thanks
B.

Hi Bobby

In C++ Value type is a type or class. As you may be know there are
two
kind of types: Fundamental types like bool, char, int and double and
User-defined data types.
Using class mechanism, we can design user-defined data types. In broad
terms,
we have two kind of C++ classes: Concrete classes and Abstract classes
Abstract classes are fundamental tools for OOP in general and
polymorphism in specific.
Concrete classes are classes that can be instansiated like Date, Time,
Point and String.
If a design of a concrete class is so good that we can use the
instance of it like
as easy as an instance of let say int or char, such concrete class is
called value type.
std::string is a typical example of great value type.
Desinging a value type is not easy. We should define special member
functions,
conversion operators, overloaded operators elegant and efficient.
Value types are fundamental tools for Value-oriented programming.
Please see the C++ Programming Language (Special Edition) by Bjarne
Stroustrup,
sections 10.3.4 and 20.3.1.

I hope it helps,
-- Saeed Amrollahi

 

[James Kanze]

what is a value type in C++ or Java or C#? Is it a class or an
object? I can see one can call a method(For instance
ToString()) on an Int16 and so on;So is it an object?At the
same time we use Int16 to instantiate a variable Int16 a =new
Int16();So is it a class?

If it is a value type, it's a class; objects aren't types.
Other than that, "value type" is a design concept, and not
really part of any of the languages, at the language level. The
exact definition probably varies somewhat (and it only has
meaning what opposed to something else, e.g. an entity type),
but roughly speaking, it's a type for which identity isn't
important, a type for which a copy of the object is as good as
the original object. The classical example of the entity type/
value type dicotomy is BankAccount/MonetaryAmount. If someone
is crediting your account, you want it to be your account, and
not some copy that will disappear after the transaction; on the
other hand you really don't care whether the amount is a copy or
not, as long as your account is credited with it.

The basic types (in C++ and in Java, at least) are all value
types. In C++, a user defined value type will support copy and
assignment; in Java, it will be final and immutable (i.e. like
java.lang.String). Each language has its own idiom for
implementing them. (Note that by default, in C++, a class is a
value type; in Java, by default, it is an entity type.)

 

[Nilone]

Hello group,

what is a value type in C++ or Java or C#? Is it a class or an object?
I can see one can call a method(For instance ToString()) on an Int16
and so on;So is it an object?At the same time we use Int16 to
instantiate a variable Int16 a =new Int16();So is it a class?

can clarify this for me?Class or Object

Thanks
B.

I've been trying to understand this topic for a while, and the
following is my current understanding of the topic. I hope that it's
accurate.

A type is a named set of values, and a value is a member of such a
set. A variable is a named area of memory which can hold values.
Types have operators that can be applied to values and variables of
the type.

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.

A class may also define a composite variable. This occurs when the
attributes of an object of the class can be modified. In this case,
the type defined by the class is not defined only by its attributes,
but also by those methods which can modify the attributes. Objects of
the class aren't values of the type, but variables which contain such
values.

'Entity classes' are a combination of value types and composite
variables. An entity class defines a set of immutable attributes,
called the identity, and a set of modifiable attributes which I'll
call properties. In this case, there are two types being defined (a
value type for the identity, and a composite variable type for the
properties). Objects of the class are both values of the first type
and variables for values of the second. It isn't clear how equality
of such objects should be defined. There are other problems
associated with entity classes, but those aren't directly related to
the topic of types and values.

There is one more set of types associated with classes. Every class
has one or more interfaces. An interface is a type, and that makes
objects of classes that implement a specific interface, values of that
type. Interfaces are used to create systems of substitutable actors.

Finally, every class is an object itself, which is defined by its
static members.

To get back to (Java or C#) Int16, when you call a method on it,
you're calling one of the methods of the static object. When you
create a new Int16 object, you're creating a new object from the
class. And Int16 just so happens to be defined as a value type, which
means Int16 objects are also values of the type of that class.

C++ int doesn't have methods, since it's a type, not a class or
object. You can, however, declare variables of int, assign int values
to them, and derive new int values via the int operators.

 

[Stefan Ram]

A type is a named set of values, and a value is a member of
such a set.

There are additional properties of types in computer
science. For example, when we ignore subtypes for a moment,
we can say that every value v belongs to exactly one type.
Your definition would allow a value to belong to several
types, as a value can be a member of several, overlapping
sets.

Also, you give no definition for »value«. So, what is a
value? To explain this, many authors also require more
structure in a type than just the set structure and deem
certain operations and other structures to be a part of the
type.

Types have operators

Now you write it yourself. But when you define a type as a
»set« it does not have operators, because a set is solely
determined by its members and has no operators.

Classes and objects are somewhat more complex.

A common description of both primitive types and
non-primitive types possibly can be given, when one sees a
type as a set of certain operations.

An interface is a type

Yes, this comes close to the idea of a type as a set of
operations. The values then possibly can be derived from
requirements on those operations. (Somewhat as in category
theory.)

That is, we begin with an

http://en.wikipedia.org/wiki/Abstract_data_type

and then we conclude the properties its values need so
as to fulfill the constrains of the ADT.

This can also be applied to primitive types, where the
operations of the type are the usual operators, like +, -,
*, /, <, >, ==, and so on for the type int.

 

[Stefan Ram]

That is, we begin with an
http://en.wikipedia.org/wiki/Abstract_data_type
and then we conclude the properties its values need so
as to fulfill the constrains of the ADT.
This can also be applied to primitive types, where the
operations of the type are the usual operators, like +, -,
*, /, <, >, ==, and so on for the type int.

A classical example is the set of the Peano axioms.

We start out without an idea of our values.

Instead, we introduce two operations »=« and »S« (successor)
and then lay out some constraints on these operations, such as:

- n=m ==> n=m
- S(n)=S(m) ==> n=m
- ..., see: http://en.wikipedia.org/wiki/Peano_axioms

. The values »natural numbers« then follow from these
constraints on these operations.

In this sense, a primitive type, such as »int«, might
be given as a set of operations in the same way as an
abstract data type is given.

 

[Nilone]

  There are additional properties of types in computer
  science. For example, when we ignore subtypes for a moment,
  we can say that every value v belongs to exactly one type.
  Your definition would allow a value to belong to several
  types, as a value can be a member of several, overlapping
  sets.

Thanks, I understood it so implicitly, but it really should be
explicitly stated.

  Also, you give no definition for »value«. So, what is a
  value? To explain this, many authors also require more
  structure in a type than just the set structure and deem
  certain operations and other structures to be a part of the
  type.


  Now you write it yourself. But when you define a type as a
  »set« it does not have operators, because a set is solely
  determined by its members and has no operators.

You're right. The operators are primary and define the type. I still
find it useful to think in terms of the "set of values" which is the
union of the ranges and domains of the operators of the type when I
program.

  A common description of both primitive types and
  non-primitive types possibly can be given, when one sees a
  type as a set of certain operations.

True, but my aim was to express the ways OO classes manipulate types
in a way that is convenient and useful for class-based imperative
programming language users.

  Yes, this comes close to the idea of a type as a set of
  operations. The values then possibly can be derived from
  requirements on those operations. (Somewhat as in category
  theory.)

My aim here was to express the relationship between types and Hewitt's
actor model from a programming point of view.

  That is, we begin with an

http://en.wikipedia.org/wiki/Abstract_data_type

  and then we conclude the properties its values need so
  as to fulfill the constrains of the ADT.

  This can also be applied to primitive types, where the
  operations of the type are the usual operators, like +, -,
  *, /, <, >, ==, and so on for the type int.

Thanks for the insight.

 

[SG]

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).

Cheers,
SG

 

[Alf P. Steinbach]

* SG:

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.

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). 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.

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

 

[Nilone]

* SG:






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.

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.

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.

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. 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.

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.

 

[Nilone]

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.

I am surprised at the similarities I find between variables and
objects as I try to respond to this. I am also surprised at your
statement, since it deviates from every description of variables and
objects I've ever seen.

Variables are not objects. Variables are known storage locations in
the context of a process or an object. Objects are units of data and
associated methods with an independent lifetime. Variables cannot be
denoted by other variables or referred to by objects. Objects can't
contain objects, but objects may contain variables which can contain
objects.

I see no benefit in describing value type as you have. It seems to me
to unnecessarily widen the gap between programming and other fields
such as mathematics and logic.

<snip the rest, we can discuss that when we are using the same
vocabulary>

 

[Alf P. Steinbach]

* Nilone:

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.

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.

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.

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

 

[SG]

I am surprised at the similarities I find between variables and
objects as I try to respond to this.  I am also surprised at your
statement, since it deviates from every description of variables and
objects I've ever seen.

Hold that thought!

Variables are not objects.  Variables are known storage locations in
the context of a process or an object.  Objects are units of data and
associated methods with an independent lifetime.

I deliberately used "variable" and "object" somewhat interchangably.
This may not match your preferred semantics but it seems to match the
ISO C++ standard's:

1.8 The C++ object model

The constructs in a C++ program create, destroy, refer to, access
and manipulate objects. An object is a region of storage. [Note:
a function is not an object, regardless of whether or not it
occupies storage in the way that objects do. -- end note] An
object can be created by a definition [...] An object has a
storage duration [...]

I have trouble figuring out how mutable objects differ from immutable
objects having your definition of "objects" in mind. Data is data.
42 will always be 42. What would be an example of a mutable object if
you use "object" more or less synonymously with "value" instead of
"region of storage"?

I see no benefit in describing value type as you have.

I don't think I described the term "value type" at all. I just named
3 examples of what we usually would consider to be a "value type" in C+
+: int, double, and a struct containing two doubles. There isn't
anything "immutable" about them even though this struct is a class
type as far as the C++ standard's type taxonomy is concerned.

we can discuss that when we are using the same vocabulary

I agree that common vocabulary is a very important. Otherwise we'd
just be wasting (more) time here.


Cheers,
SG

 

[Nilone]

* Nilone:





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..

I agree with that.

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.

I agree that they're distinct. I may not not be expressing myself
clearly. I realize that there are no values of your type as defined.
However, I could complete your incomplete type, which would be a
subtype of the incomplete type, and the values it would define would
also be values of the incomplete type.

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.

How about you contribute your definition of type, instead of typing
adjectives? The value set definition was a common one, and not
crucial to the rest of my post. Let's use Stefan's definition of a
type by its operators, unless you've got something better.

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 define both as value types, and Integer as a subtype of
RationalNumber. The constructor of Integer sets q to the value of the
constructor's parameter and d to 1. Note that my definition of a
value type required immutability, so an Integer is a subtype of a
RationalNumber.

If you want to discuss variable data structures, note that my
definition requires that you consider mutators as part of the type
itself (and this applies to directly accessible members too), so an
Integer variable type is not a subtype of a RationalNumber variable
type, since it would inherit RationalNumber's mutators which is not
appropriate.

I don't recognize overriding of inherited behavior as a valid
operation in a discussion of types, since it nearly always breaks LSP.

No, just start and end with Liskov. ;-)

Not mentioning Barbara Liskov is serious omission. Thanks for the
correction.

 

[Nilone]

I am surprised at the similarities I find between variables and
objects as I try to respond to this.  I am also surprised at your
statement, since it deviates from every description of variables and
objects I've ever seen.

Hold that thought!

Variables are not objects.  Variables are known storage locations in
the context of a process or an object.  Objects are units of data and
associated methods with an independent lifetime.

I deliberately used "variable" and "object" somewhat interchangably.
This may not match your preferred semantics but it seems to match the
ISO C++ standard's:

  1.8  The C++ object model

  The constructs in a C++ program create, destroy, refer to, access
  and manipulate objects.  An object is a region of storage.  [Note:
  a function is not an object, regardless of whether or not it
  occupies storage in the way that objects do. -- end note]  An
  object can be created by a definition [...] An object has a
  storage duration [...]

It is an interesting point of view. However, I believe the
differences are significant enough to justify separate terms. In
particular, polymorphism requires that one distinguish between the two
for the purpose of typing.

BTW, I consider a function to be a value - its type is the function
signature. This begs the question of equality, which I required in my
definition of a value. Equivalence of two functions aren't decidable
in general, but straight equality of the code or parse tree is, and is
still useful from a behavioral subtyping point of view. Furthermore,
functions are objects too, in Java and C#.

I have trouble figuring out how mutable objects differ from immutable
objects having your definition of "objects" in mind.  Data is data.
42 will always be 42.  What would be an example of a mutable object if
you use "object" more or less synonymously with "value" instead of
"region of storage"?

I certainly don't equate object with value! I consider values to be
immutable: the integer 42, the date 10/24/2009, the point (x=3,y=4),
the circle (x=10,y=10,r=7.5). A value type would be a type which
defines/creates such values, e.g. C++ int, or immutable date, point
and circle classes.

A point2d struct which allows its members to be modified directly or
via methods would create mutable objects. A mutable object isn't a
value, although the values of its variables at any particular time
would define a value of the composite type. I prefer to call these
variable types since subtyping is different than for value types.

I don't think I described the term "value type" at all.  I just named
3 examples of what we usually would consider to be a "value type" in C+
+: int, double, and a struct containing two doubles.  There isn't
anything "immutable" about them even though this struct is a class
type as far as the C++ standard's type taxonomy is concerned.

int and double aren't the same as the struct. An int variable holds
int values. A variable of the struct holds an object containing two
double variables.

 

[Alf P. Steinbach]

* Nilone:

How about you contribute your definition of type, instead of typing
adjectives? The value set definition was a common one, and not
crucial to the rest of my post. Let's use Stefan's definition of a
type by its operators, unless you've got something better.

Much of the point is that there's no single definition of "type" that's suitable
for all types and programming languages.

To take but one simple example, you started out with a requirement that a type
has a name. And in the example I gave of a practically useful incomplete C++
type the name was crucial: the name, and its scope attribute, was the /only/
property of that type! But when in C++ you write (void*)p, perhaps in order to
output a textual representation of p, then you're using an anonymous type, one
with no name -- so these two types have apparently /nothing/ in common...

Of course what they do have in common is what you can do with them in an outer
environment, such as (in C++) using them as template parameters.

And that leads to an operative definition of "type": something is a "type" if it
can be used as a type -- inherent properties such as a possible value set
don't really count, they merely serve to help one particular usage or another.

That's what makes purported general definitions of "type" so hopelessly
misguided. A lot of rigor applied to defining a chair as having a seat and four
legs and back and so on. Thus excluding quite a lot of real-world chairs
(they're chairs because they can be used or are used as chairs)...

And different programming languages have different notions of type, and some,
like C++, have a multitude of notions of type.

And so much of the point is also what James Kanze wrote: that "value type" is a
design level notion, which can't really be rigorously defined (because the act
of doing so loses the concept's usefulness, like a rigorous definition of chair)
but is mostly understood in terms of whether object identity matters or not.
When you see it you can recognize it, and when you say it, most people
understand what you mean, in the sense that it refers to the things they will
recognize as value types. But I strongly doubt that a general definition of the
formal kind is possible, and even if it were, would be of practical value.

Formal definitions are nice & useful for reasoning about things as long as one
is very aware that one is considering a very limited, simplified model.

But it's just ungood to try to impose them on the world, or use them as
classifiers, lest you end up with a baggy chair classified as non-chair...


Cheers & hth.,

- Alf

 

[Keith H Duggar]

Not mentioning Barbara Liskov is serious omission. Thanks for the
correction.

Sadly you are both missing the fathers of this line of work
namely (as far as I know) Guttag, Birkhoff, and Lispon. See
for example

Birkhoff and Lipson
Heterogeneous Algebras
Journal of Combinatorial Theory, 8:115-133, 1970

Guttag
Abstract Data Types and the Development of Data Structures
Communications of the ACM, 20(6):396-404, 1977

which are exactly relevant. Not to mention that Jeannette Wing
who with Liskov developed LSP subtyping notions was trained, as
a PhD student, by Guttag. So one can hardly "start and end with
Liskov" and expect to actually learn the topic appreciatively.

And really, depending on where you draw the line of exactly
what we are talking about here, you can trace further back to
the earliest 1900s to say Russell.

But really, what does all this name dropping have to do with
anything? It would be better to point a few (say 1 to 2) of
the specific works that you think best describe the notion
of type that you think most applies here.

KHD