Most specific superordinate concept of variable and method?

[Stefan Ram]

Certain identifiers in Java designate either a
variable or a method.

For example, in

void example( final java.awt.geom.Point2D.Double point )
{ return point.x + point.getY(); }

»point.x« is a variable, while »point.getY« is a method.

So, it seems to me that one can teach that <object>.<name>
or simply <name> always designates either a variable or a
method, whenever <name> is written with a lowercase first
letter (and is not a package name). (Even if you could find
some exception to this rule, I would like to use this
as a simplification for beginners classes.)

Now, it would be niece if there would be a handy
superordinate concept »?« of variable and method, so that
could say that such a name always designates a »?«.

I could use »entity«, but that would be too broad, because
there are more entities than just variables and methods.

I could use »member«, but that reminds much of C++ and also
would only apply to <object>.<name>, but not to a simple <name>.

So, does anyone know a most specific superordinate concept
of variable and method, that is a word that designates both
variables and methods, but not much more?

For example, the most specific superordinate concept of
cat and dog I can find right now is »Carnivora«. »Mammalia«
also is a superordinate concept, but less specific; while
»Canidae« is too specific, because it applies to dogs only.

 

[Lew]

Certain identifiers in Java designate either a
variable or a method.

For example, in

void example( final java.awt.geom.Point2D.Double point )
{ return point.x + point.getY(); }

»point.x« is a variable, while »point.getY« is a method.

And both are members of 'Point2D.Double', as 'Point2D.Double' is a member of
'Point2D'.

So, it seems to me that one can teach that <object>.<name>
or simply <name> always designates either a variable or a
method, whenever <name> is written with a lowercase first
letter (and is not a package name). (Even if you could find
some exception to this rule, I would like to use this
as a simplification for beginners classes.)

Now, it would be niece if there would be a handy
superordinate concept »?« of variable and method, so that
could say that such a name always designates a »?«.

I could use »entity«, but that would be too broad, because
there are more entities than just variables and methods.

I could use »member«, but that reminds much of C++ and also
would only apply to <object>.<name>, but not to a simple <name>.

So, does anyone know a most specific superordinate concept
of variable and method, that is a word that designates both
variables and methods, but not much more?

For example, the most specific superordinate concept of
cat and dog I can find right now is »Carnivora«. »Mammalia«
also is a superordinate concept, but less specific; while
»Canidae« is too specific, because it applies to dogs only.

I don't think there is one. In your specific example of something to the
right of a "dot", the superordinate (cool word) is "member". Methods, of
course, cannot be anything but members. But a local variable doesn't share a
superordinate with methods that I can think of other than "thingie".

Think from your own perspective - what do methods and variables share, other
than being Java fundamentals?

I don't find the search for a common concept very useful. What's the
superordinate between a boulder and a dog? Both occur in nature.

 

[Lew]

For example, the most specific superordinate concept of
cat and dog I can find right now is »Carnivora«. »Mammalia«
also is a superordinate concept, but less specific; while
»Canidae« is too specific, because it applies to dogs only.

"Housepet" is more specific still. "Housepet that requires a license by law
in <such-and-such jurisdiction>" is more specific still. "Four-footed
mammalian housepet" more specific still. "Four-footed mammalian housepet of
the same species that I used to have when I was a kid" is even more specific.
"Four-footed mammalian housepet of the same species that has millions of
devotees and that I used to have when I was a kid" more so yet. "Four-footed
mammalian housepet of the same species that has millions of devotees and that
I used to have when I was a kid and has in historic times been worshiped as
the holy representative of a god" more so yet. "Four-footed mammalian
housepet of the same species that has millions of devotees and that I used to
have when I was a kid and has in historic times been worshiped as the holy
representative of a god and of whom a representative has eaten the country ham
we planned for dinner" more so yet again. "Four-footed mammalian housepet of
the same species that has millions of devotees and that I used to have when I
was a kid and has in historic times been worshiped as the holy representative
of a god and of whom a representative has eaten the country ham we planned for
dinner and ..."

 

[markspace]

I could use »entity«, but that would be too broad, because
there are more entities than just variables and methods.

It is in fact "member" if I understand what you are saying:


The members of a class type (§8.2) are classes (§8.5, §9.5), interfaces
(§8.5, §9.5), fields (§8.3, §9.3, §10.7), and methods (§8.4, §9.4).
Members are either declared in the type, or inherited because they are
accessible members of a superclass or superinterface which are neither
private nor hidden nor overridden (§8.4.6).


<http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html#34757>

Now that include more than just methods and variables, so maybe that's
what you are referring to, there's no one word for just variable|method,
but it is ok to refer to those two as members, because the JLS does.

 

[Lew]

Now that include more than just methods and variables, so maybe that's
what you are referring to, there's no one word for just variable|method,
but it is ok to refer to those two as members, because the JLS does.

Unless the variables are not members.

 

[Mike Schilling]

Unless the variables are not members.

Right. If I were going to taxonomize names used in Java, local variables
and fields would be more closely related than fields and methods. The
result would look something like

namedObjects : packages types methods entities
types: primitiveTypes referenceTypes
referenceTypes: interfaces classes
entities: localVariables fields