tags:

views:

136

answers:

5

This might be an odd question, but it has actually caused me some headache.

In Object oriented programming, there are accepted names for key concepts. In our model, we have classes with methods and fields. Now, going to the data world:

  • An instance of a class is called an object.
  • An instance of a field is called... what?

A value? Isn't the term value a little broad for this? I have been offered "property" as well, but isn't property also part of the model and not the data?

(This is not purely academic, I am actually coding these concepts.)

Updated: Let me take an example. I have a class "Person" with a field "age". If I create 20 Person instances, each such instance is called an object. So far so good. But let's say I take Person "Igor", and set his age to 20. What is the storage location that contains the number 20 now called? Is it a field, or a value, or something else?

Another update: A quote from Pavel Feldman in this related question describes in different words what I tried to describe above:

"I'd say that in class-based OOP field belongs to class and does not have a value. It is so when you look at reflection in c# or java - class has fields, field has type, name, etc. And you can get value of the field from object. You declare field once, in class. You have many objects with same fields but different values."

+8  A: 

A field can't be instantiated. A field can only contain a value. The value can be either a primitive/native type or a reference/pointer to an object instance.


As per your update: if the object represents a real world entitiy, then it's often called property. With a "real world entity" I mean something personal/human, e.g. Person, Product, Order, Car, etc. If the object does not represent something personal/human, e.g. List, String, Map, then it's more often called field. That's just what I've observed as far.

BalusC
I updated my question slightly with an example. I agree with the notion that a field is not instantiated, but I still think there exists a difference between the field as part of a class definition and field as a storage location for an object.
waxwing
I finally went with "property" - this is actually what a colleague suggested before I asked this question, but I did not agree with him. I am still not sure that I do...
waxwing
+2  A: 

A field is a field weather you talk about it in the context of a class, or in the context of an object.

class C {
    int i;       // i is a field
}

and

obj = new C();
obj.i = 7;       // obj.i is a field

As opposed to parameter vs argument there is no distinction in terminology for "instantiated" an "uninstantiated" fields.

aioobe
Very clear example of what I was trying to say, thanks!
waxwing
+3  A: 

Agree with BalusC. However I think what you are asking is what to call the field of an instantiated object. Remember that an object contains both state (data) and operations (methods) you could refer to an object field as state

Adrian Regan
A: 

An instance of a class is an object, a class may contain fields that point to other instantiated objects (or a null pointer). It makes no sense to say an instance of a field, but rather you might talk about the object to which a particular field points to, which may be different for different instances. Or you may talk about the type of a field (which class it belongs to)

Robert
A: 

Isn't the answer basically that we have no name for values of fields of an instance of a class (or object)?

It's like giving a name to the value returned by a method of an instance of a class...

I guess "state" is the best answer anyway as suggested "BalusC".

JSmaga