terminology

[Stefan Ram]

Sometimes, I was being criticized for making up non-standard
terminology. If there is a standard term for the following,
then please tell me so:

In

java.lang.Thread . dumpStack()
java.lang.System.out . print( 2 )

I do call the source code part in front of the last dot a
/context/.

I do call the simple name between the last dot and the first
parentheses a /verb/. (So a verb does never contain a dot.)

(I do /not/ call this »method name«, since I want to exclude
texts with dots, like »>java.lang.Thread.dumpStack«, which
are also method names in Java AFAIK.)

I do call the simple call after the last dot up to the last
parentheses a /sentence/.

(I do /not/ call this »[method ]call«, since the whole lines
including the dots are also called »[method ]calls« or
»[method ]invocations« in Java.)

context sentence
..------------------. .------------.
java.lang.Thread . dumpStack()
java.lang.System.out . print ( 2 )
'-------'
verb
'------------------------------'
not a verb, because of dots
'-----------------------------------'
not a sentence, because of dots

Ok, »context« /is/ a standard JLS term, but »verb« is less
so (although sometimes used in OOP, IIRC), and »sentence«
was invented by me, but seems natural, once one accepts »verb«.

However, if there are already standard Java terms for this,
I'd gladly use them.

 

[Lew]

Sometimes, I was being criticized for making up non-standard
terminology. If there is a standard term for the following,
then please tell me so:

In

java.lang.Thread . dumpStack()
java.lang.System.out . print( 2 )

I do call the source code part in front of the last dot a
/context/.

Fully-qualified type name.

I do call the simple name between the last dot and the first
parentheses a /verb/. (So a verb does never contain a dot.)

Simple method name.

(I do /not/ call this »method name«, since I want to exclude
texts with dots, like »>java.lang.Thread.dumpStack«, which
are also method names in Java AFAIK.)

Qualified method name.

I do call the simple call after the last dot up to the last
parentheses a /sentence/.

Method invocation expression, except that includes the qualifier. There is no standard term for what you call a "sentence", nor would most Java programs have the faintest clue what you mean by that word.

(I do /not/ call this »[method ]call«, since the whole lines
including the dots are also called »[method ]calls« or
»[method ]invocations« in Java.)

There's always a qualifier in a method invocation, so there is no such thing as an invocation without one. The qualifier is just implicit by the graceof 'import', but it's explicit in the JVM regardless.

To be consistent with Java terminology, use the term "simple method invocation", which is not official but at least it's explicable.

context sentence
.------------------. .------------.
java.lang.Thread . dumpStack()
java.lang.System.out . print ( 2 )
'-------'
verb
'------------------------------'
not a verb, because of dots
'-----------------------------------'
not a sentence, because of dots

Ok, »context« /is/ a standard JLS term, but »verb« is less

"Context" in the JLS has several meanings, all identical to the standard English usage, not a technical context:
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.5.1>
Here are a few of them:

- In a package declaration (§7.4)
- To the left of the "." in a qualified PackageName
- In a single-type-import declaration
- To the left of the "." in a single-static-import declaration
- To the left of the "<" in a parameterized type
- In an explicit type argument list in a method or constructor invocation
- As a PostfixExpression
- Before the "(" in a method invocation expression
- To the left of the "=" sign in an annotation's element value pair

and many more. Your attempt to reduce "context" to one specific construct amongst this plethora is at variance with Java's terminology.

so (although sometimes used in OOP, IIRC), and »sentence«
was invented by me, but seems natural, once one accepts »verb«.

However, if there are already standard Java terms for this,
I'd gladly use them.

Quite frankly I'm surprised that you aren't already using the terms definedin the JLS where they exist, and following their pattern when they don't. I'm especially surprised that you'd use terms differently from how they do ("context"). I strongly suggest that you use the terminology from the JLS.

 

[markspace]

Fully-qualified type name.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.5.5.2>

I'd have said the same off the top of my head. I'd also call it a
"class" if FQN was a bit long, or I was being less strict in my speaking.

Simple method name.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.5.7.1>

"Method" or "method invocation" works for me.

Qualified method name.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.5.7.2>

Or identifier, or "method name," imo.

Method invocation expression, except that includes the qualifier.
There is no standard term for what you call a "sentence", nor would
most Java programs have the faintest clue what you mean by that
word.
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12>

Also "statement" if there's a ; at the end, I think.

(I do /not/ call this »[method ]call«, since the whole lines
including the dots are also called »[method ]calls« or »[method
]invocations« in Java.)

There's always a qualifier in a method invocation, so there is no
such thing as an invocation without one. The qualifier is just
implicit by the grace of 'import', but it's explicit in the JVM
regardless.

I'm not sure. If you're invoking a method that is a member of an
enclosing class or type, you don't need to qualify it. "wait()",
"notify()", etc. never need to be qualified if "this" is the qualifier.

As for "the whole line is an invocation," this is a statement with two
invocations:

double d = Math.sin(1.0) + Math.cos(1.0);

I don't think the "whole line" can be an invocations, it's just that you
happen to have a method call, expression, and statement that are all the
same thing in that one particular example. That won't always be true.

 

[Stefan Ram]

I'd have said the same off the top of my head. I'd also call it a
"class" if FQN was a bit long, or I was being less strict in my speaking.

A »type name« is a special kind of context, it is a static context.
My usage does not come from the JLS, but from javac who says things like:

Main.java:7: error: non-static method length() cannot be referenced from a static context
String.length();
^
1 error

When you teach java, explaining vocabulary of javac can't be
that wrong, even if it's not as authoritative as the JLS.
Obviously, the »static context« above is »String«.

I cannot call this »type name«, since the part in front of
the last dot is not always a type name, as in

java.lang.System.out . println()

. »java.lang.System.out« is the context of »println()«
(in my terms), but it is not a type name.

I already gave this example in my OP, but it got lost
somewhere. The javac compiler seems to call this a
non-static context (by analogy from the above message).

"Method" or "method invocation" works for me.

Obviously, these are all different things: A method is not
a method name, and a method is not a method invocation.

Some, albeit slight, justification of my term »verb« comes
from the JLS 7, which says in 6.1:

"Method names should be verbs".

 

[Arved Sandstrom]

On 12-04-20 01:40 AM, Stefan Ram wrote:
[ SNIP ]

Obviously, these are all different things: A method is not
a method name, and a method is not a method invocation.

Some, albeit slight, justification of my term »verb« comes
from the JLS 7, which says in 6.1:

"Method names should be verbs".

It occurs to me that you'd like J, at least for the terminology. All
sentences in J are composed of verbs and nouns and copulas and adverbs
and conjunctions.

AHS

 

[Lew]

I'd have said the same off the top of my head. I'd also call it a
"class" if FQN was a bit long, or I was being less strict in my speaking.

A »type name« is a special kind of context, it is a static context.
My usage does not come from the JLS, but from javac who says things like:

Main.java:7: error: non-static method length() cannot be referenced from a static context
String.length();
^
1 error

When you teach java [sic], explaining vocabulary of javac can't be
that wrong, even if it's not as authoritative as the JLS.
Obviously, the »static context« above is »String«.

No. 'String' is the (simple) type name. The static context is the semantic
space to the right of the dot.

I cannot call this »type name«, since the part in front of
the last dot is not always a type name, as in

java.lang.System.out . println()

. »java.lang.System.out« is the context of »println()«
(in my terms), but it is not a type name.

"Context" is a general term, and the javac output is using it exactly as the
JLS does. Static contexts occur other than by a type name, e.g.,:

public class Foo
{
static
{ // static context
}
}

There is nothing wrong with using these terms as the JLS does.

When you teach Java, the vocabulary of the JLS can't be wrong. (Well, there
are questionable items in there, but that's another matter.) Trying to go
against it, especially diametrically, can be.

More subtly, you misidentified the static context in the 'String' call to
'length()'. "Context" is used in its ordinary, English sense in the JLS, and
in the concomitant "javac" output. It means, in that example, that at the
point of evaluation of the method name, that is, to the right of the dot, the
semantic environment is that of the type specified by the type name to the
left of the dot. By the rules of Java, since it's a type name and not an
instance name, the context is static. Likewise in a static initializer, to
between the braces is a static context. "Context" means the environment or
ontological background - are we looking at the world from the class-wide
(static) view or the instance view?

I aver that you're going about this backwards, thus impeding understanding of
Java. Instead of trying to map your terms to what exists in Java, start with
the Java terminology and grok what they really mean. Then, if you still really
feel the need, come up with synonyms, rather than shoehorning alien concepts
into the Java space.

 

[markspace]

Obviously, these are all different things: A method is not
a method name, and a method is not a method invocation.

Right. It's "method" or "method name" if you mean just the method, and
"invocation" if you're referring to the act of making the call. Since
some different concepts were being tossed around, I gave both answers.

 

[Stefan Ram]

A »type name« is a special kind of context, it is a static context.

JLS 7 defines »static context« in 8.1.3, but the compiler
uses another meaning of »static context«.

For example, the call »dumpStack()« in

class A { void m(){ java.lang.Thread.dumpStack(); }}

is /not/ in a static context according to JLS 7 8.1.3,
but /is/ according to javac.

One reason for this possibly is that JLS 1 did not yet
define »static context«, so the wording of the compiler
message might predate the first definition of »static
context« in the JLS.

 

[Lew]

JLS 7 defines »static context« in 8.1.3, but the compiler
uses another meaning of »static context«.

For example, the call »dumpStack()« in

class A { void m(){ java.lang.Thread.dumpStack(); }}

is /not/ in a static context according to JLS 7 8.1.3,

Incorrect. The statement 'Thread.dumpStack();' is not in a static context. The
simple method name 'dumpStack()' is.

I see in
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.1.3>
that is says,
"A statement or expression occurs in a static context if and only if the
innermost method, constructor, instance initializer, static initializer, field
initializer, or explicit constructor invocation statement enclosing the
statement or expression is a static method, a static initializer, the variable
initializer of a static variable, or an explicit constructor invocation
statement (§8.8.7)."

There are two contexts operating here. 'dumpStack()' occurs in a static
context established by the symbol 'Thread' and the dot. The entire expression,
or statement, 'Thread.dumpStack();' [*] occurs in a non-static context
established by the opening curly brace of the instance method definition.

but /is/ according to javac.

One reason for this possibly is that JLS 1 did not yet
define »static context«, so the wording of the compiler
message might predate the first definition of »static
context« in the JLS.

[*] Why the heck do you insist on calling out 'java.lang'? It's highly
unconventional and not at all idiomatic for Java.

 

[Jan Burse]

context sentence
.------------------. .------------.
java.lang.Thread . dumpStack()
java.lang.System.out . print ( 2 )
'-------'
verb
'------------------------------'
not a verb, because of dots
'-----------------------------------'
not a sentence, because of dots

Hi,

If you are up at applying linguistic
categories to parts of Java programs,
then the most successful approach would be:

+---------------- Sentence ----------------+
| |
java.lang.System.out . print ( 2 )
| | | |
+---- Subject -------+- Verb ---+- Object -+

This would make an English speaking person
very much at home, since English is typicall
a SVO language. A German speaking person can
less relate to this pattern, since his languages
is judged a SOV language.

But libraries and applications,
the classes and methods they defined, the
names that are used, need not match the
categories of some known natural languages.
Natural language verbs might have implicit
arguments which need to be made explicit
in code, which goes beyond a "this".

Nevertheless the SOV view of a code can
be very useful for problem analysis.
Especially on a higher level. This
is best viewed by the CRC method.

The classes are the subjects/actors you name
it. The resposibilities are the verbs/
steps you name it. The collaborators are
some objects/other actors you name it. CRC
cards can be elicidated by a simple role play:

- Take a group of people that are about
to execute a sequential use case and a
ball. Give the ball to the first member of
the group.

- The member of the group who has the ball
should say his role and what step he is
performing, and hand the ball to an
appropriate next member of the group.

- Write a prose flow chart of the session,
this is your use case. Let the members of
the group take notes of their steps and
collaborates, this is the component design.

I had once an idea to elaborate concurrent
interaction protocols by using multiple
balls, but had never the chance to do this
in real life. Maybe would end in
battle ball...

http://en.wikipedia.org/wiki/Subject–verb–object

http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

 

[Jan Burse]

- Take a group of people that are about
to execute a sequential use case and a
ball. Give the ball to the first member of
the group.

- The member of the group who has the ball
should say his role and what step he is
performing, and hand the ball to an
appropriate next member of the group.

Forgot to say:
- Repeat the whole procedure for different
scenarios.

 

[Stefan Ram]

context sentence
.------------------. .------------.
java.lang.Thread . dumpStack()
java.lang.System.out . print ( 2 )
'-------'
verb

I just found some support here:

»LINGUISTIC METAPHORS IN SOFTWARE DESIGN«

(...)

»Messages resemble sentences
Method names resemble verb and noun phrases«

http://www.educery.com/papers/rhetoric/road/

(But the second observation makes me think about
using »word« instead of »verb«.)

 

[Jan Burse]

I just found some support here:

»LINGUISTIC METAPHORS IN SOFTWARE DESIGN«

(...)

»Messages resemble sentences
Method names resemble verb and noun phrases«

http://www.educery.com/papers/rhetoric/road/

(But the second observation makes me think about
using »word« instead of »verb«.)

Word is probably to general. For example a
number 123 is also a word. But it will never
occur in a method name position.

That "Method names resemble verb and noun phrases"
is a kind of a praxis in building method names
that are not only verbs, but that also indicate
the arguments of the verbs:

So instead of having a method declaration:

checking(String business, String number)

One sees:

checkingAccount(String business, String number)

But I would even prefer:

checkingByBusinessAndNumber(String business, String number)

Thus the best long method names are actually:

verb +
{ preposition +
noun }

The preposition+noun pairs should be given in the same
order as the method arguments appear in their declaration.
conjunctions can be used shorten the long method names.

But some hard core oponents would say not enough OO-fication
has been applied. Namely no class Account has be defined.
If there were a class Account one could simply declare:

static void checking(Account a)

Or even do it more OO-ish:

class Account {
void checking();
}

And everything would be clear. Right?

Bye

 

[Jan Burse]

But some hard core oponents would say not enough OO-fication
has been applied. Namely no class Account has be defined.
If there were a class Account one could simply declare:

static void checking(Account a)

Or even do it more OO-ish:

class Account {
void checking();
}

And everything would be clear. Right?

Oops, the CheckingAccount from the paper is a factory method,
which has a result value. So the above doesn't work. Forget
about it...

 

[Jan Burse]

Method names resemble verb and noun phrases«

http://www.educery.com/papers/rhetoric/road/

(But the second observation makes me think about
using »word« instead of »verb«.)

Ok after the little excursion posts from
before I now understand the "resemble" as:

Method names either resemble verb or noun phrases

Yes thats true. Noun phrases make good factory
method names. Judging from the paper the above
seems not be inclined with argument identifications.

So what is a general term for verbs and nouns?
The problem here is that a noun phrase can be
both a subject and an object. So noun phase is
already an imprecise criteria.

But I would say the SVO pattern can be sustained.
One does not simply walk into Mordor and drop
the verb. What is often seen for factory methods
is that nevertheless a verb is injected.

For example one finds even:

public static final DateFormat getDateInstance()

Bye

 

[John B. Matthews]

I just found some support here:

»LINGUISTIC METAPHORS IN SOFTWARE DESIGN«

(...)

»Messages resemble sentences
Method names resemble verb and noun phrases«

http://www.educery.com/papers/rhetoric/road/

(But the second observation makes me think about
using »word« instead of »verb«.)

The combination of a verb plus a noun phrase makes me think of a
grammatical predicate

<http://en.wikipedia.org/wiki/Predicate_(grammar)>,

but predicate can also mean the result of evaluating a logical
expression.

 

[Jan Burse]

The combination of a verb plus a noun phrase makes me think of a
grammatical predicate

<http://en.wikipedia.org/wiki/Predicate_(grammar)>,

but predicate can also mean the result of evaluating a logical
expression.

In the SVO pattern, the predicate (traditional,
Aristotele) is more or less the VO part.

+---------------- Sentence ----------------+
| |
java.lang.System.out . print ( 2 )
| | | |
+---- Subject -------+- Verb ---+- Object -+
| |
+----- Predicate -----+

What you learn in school is:
The predicate is one of the two main parts of
a sentence (the other being the subject, which
the predicate modifies). The predicate must
contain a verb (watch out Mordor), and the
verb requires, permits, or precludes other
sentence elements to complete the predicate.

Bye

 

[Lew]

The combination of a verb plus a noun phrase makes me think of a
grammatical predicate

<http://en.wikipedia.org/wiki/Predicate_(grammar)>,

but predicate can also mean the result of evaluating a logical
expression.

Stefan introduces a useful and productive exercise, mapping the specialized
terms of art for Java to the wider world of terms from programming and the
real world.

I favor using the terms of art when having a discussion within that context,
that is, use the Java terms when talking of Java particularly. I favor what
Stefan is doing, connecting to other terms of varying synonymity, to deepen
understanding and to discuss matters intelligibly outside the world of Java.

It's important to understand that cognate terms vary from literally equivalent
to fancifully metaphoric and most in between. A sentence is a statement in
linguistics, so the Java term "statement" may fairly map to "sentence" as a
metaphoric or general term. However, calling it a "sentence" whilst reviewing
a program will jar, pun intended. Back on the plus side, if you know that a
Java statement constitutes the sentence of its world, you could be the better
programmer.

Be prepared for folks to differ from you on the generalized terminology, but
stand your ground on the terms of art.