Is there a term for "signature plus return type"?

[Stefan Ram]

Given the declaration

int f( final int x ){ return x }

, »f( int )« is called the »signature of f«.

Does the JLS also has a term for »int f( int )«, that is,
»signature plus return type«? (A term that is shorter than
»signature plus return type«, of course.)

(Personally, I'd call it the »type of f« or »interface of f«,
but this might be misleading, since »type« and
»interface« already have other meanings in the JLS.)

 

[Stefan Ram]

(Personally, I'd call it the »type of f« or »interface of f«,
but this might be misleading, since »type« and
»interface« already have other meanings in the JLS.)

It is the »type« of the method in the sense of typed
lambda calculus, according to:

»The type of a term should tell us what kind of
arguments the term would accept and what kind of result
it will produce. For example, the type of the sine
function should be "accepts real numbers and produces
real numbers".«

http://www.cs.bham.ac.uk/~axj/pub/papers/lambda-calculus.pdf

But I do not think that this notion of »type of a method«
exists in the JLS, or does it?

To a Java programmer, »type of a method« might mean the
»return type« only, not a type in the sense of the quotation.

 

[Joshua Cranmer]

Does the JLS also has a term for »int f( int )«, that is,
»signature plus return type«? (A term that is shorter than
»signature plus return type«, of course.)

The JVM uses method descriptors, which include the return type (although
it also uses erased versions of the arguments). The signature attribute
also includes the return type, though.

I think I would call it the "full signature" of the method, but I don't
think the JLS ever refers to it as such.

 

[Mike Schilling]

Given the declaration

int f( final int x ){ return x }

, »f( int )« is called the »signature of f«.

Does the JLS also has a term for »int f( int )«, that is,
»signature plus return type«? (A term that is shorter than
»signature plus return type«, of course.)

(Personally, I'd call it the »type of f« or »interface of f«,
but this might be misleading, since »type« and
»interface« already have other meanings in the JLS.)

In Java, the signature is a unique key, but in the JVM it isn't. I wonder
if the JVM spec has a name for signature+return type, or if it just uses
"signature".

 

[Lew]

  It is the type of the method in the sense of typed
  lambda calculus, according to:

      The type of a term should tell us what kind of
      arguments the term would accept and what kind of result
      it will produce. For example, the type of the sine
      function should be "accepts real numbers and produces
      real numbers".

http://www.cs.bham.ac.uk/~axj/pub/papers/lambda-calculus.pdf

  But I do not think that this notion of type of a method
  exists in the JLS, or does it?

  To a Java programmer, type of a method might mean the
  return type only, not a type in the sense of the quotation.

JLS § 8.2 defines,

We use the phrase /the type of a member/ to denote:
- For a field, its type.
- For a method, an ordered 3-tuple consisting of:
o *argument types*: a list of the types of the arguments to the method member[;]
o *return type*: the return type of the method member[;] and the
o *throws clause*: exception types declared in the throws clause of the method member.

Additional information:

§ 13.1 of the JLS calls the whole shebang, "the erasure ... of the
qualifying type of the [method] invocation, plus the erasure of the
signature of the method." This applies to method invocations.

§ 15.12.3 tells us, "If the compile-time declaration for the method
invocation is not void, then the type of the method invocation
expression is the result type specified in the compile-time
declaration."

 

[Arne Vajhøj]

The JVM uses method descriptors, which include the return type (although
it also uses erased versions of the arguments). The signature attribute
also includes the return type, though.

I think I would call it the "full signature" of the method, but I don't
think the JLS ever refers to it as such.

I think we should agree here on cljp that this is the correct term
and push it to the rest of the world!



Arne

 

[Lew]

I think we should agree here on cljp that this is the correct term
and push it to the rest of the world!

Or we could agree to use the term already defined in the JLS.

Is it such a bad thing to use the definitions in the standard?

 

[Arne Vajhøj]

Or we could agree to use the term already defined in the JLS.

And that was?

Is it such a bad thing to use the definitions in the standard?

No.

Arne

 

[Roedy Green]

I think I would call it the "full signature" of the method, but I don't
think the JLS ever refers to it as such.

If you start making the distinction consistently in your docs others
will almost subliminally understand. Further, if an official term
does come into being, you can update all your docs with a global regex
string Search and replace.
see http://mindprod.com/jgloss/searchreplace.html

Any project needs a project dictionary with precise definitions. You
need to take generic English language and nail it down with project
specific definitions. If you don't, your docs will use a hodge podge
of conflicting terms. This vocabulary and accurate docs using it make
updating code a piece of cake. Without it, you will make all manner of
incorrect assumptions.

When I work on my own, I keep renaming things to use ever more precise
terminology. Keep it consistent!

 

[Lew]

Or we could agree to use the term already defined in the JLS.

And that was?

JLS § 8.2 defines,

We use the phrase /the type of a member/ to denote:
- For a field, its type.
- For a method, an ordered 3-tuple consisting of:
o *argument types*: a list of the types of the arguments to the method member[;]
o *return type*: the return type of the method member[;] and the
o *throws clause*: exception types declared in the throws clause of the method member.

Additional information:

§ 13.1 of the JLS calls the whole shebang, "the erasure ... of the
qualifying type of the [method] invocation, plus the erasure of the
signature of the method." This applies to method invocations.

§ 15.12.3 tells us, "If the compile-time declaration for the method
invocation is not void, then the type of the method invocation
expression is the result type specified in the compile-time
declaration."

It was and still is.

 

[Lew]

Joshua Cranmer wrote, quoted or indirectly quoted someone who said :

If you start making the distinction consistently in your docs others
will almost subliminally understand. Further, if an official term
does come into being,

JLS § 8.2 defines,

We use the phrase /the type of a member/ to denote:
- For a field, its type.
- For a method, an ordered 3-tuple consisting of:
o *argument types*: a list of the types of the arguments to the method member[;]
o *return type*: the return type of the method member[;] and the
o *throws clause*: exception types declared in the throws clause of the method member.

you can update all your docs with a global regex string Search and replace.
see http://mindprod.com/jgloss/searchreplace.html [snip]
When I work on my own, I keep renaming things to use ever more precise
terminology. Keep it consistent!

 

[Roedy Green]

I think I would call it the "full signature" of the method, but I don't
think the JLS ever refers to it as such.

If you start making the distinction consistently in your docs others
will almost subliminally understand. Further, if an official term
does come into being, you can update all your docs with a global regex
string Search and replace.
see http://mindprod.com/jgloss/searchreplace.html

Any project needs a project dictionary with precise definitions. You
need to take generic English language and nail it down with project
specific definitions. If you don't, your docs will use a hodge podge
of conflicting terms. This vocabulary and accurate docs using it make
updating code a piece of cake. Without it, you will make all manner of
incorrect assumptions.

When I work on my own, I keep renaming things to use ever more precise
terminology. Keep it consistent!

 

[Tom McGlynn]

I think we should agree here on cljp that this is the correct term
and push it to the rest of the world!

Or we could agree to use the term already defined in the JLS.

And that was?

JLS § 8.2 defines,
We use the phrase /the type of a member/ to denote:
- For a field, its type.
- For a method, an ordered 3-tuple consisting of:
   o *argument types*: a list of the types of the arguments to the method member[;]
   o *return type*: the return type of the method member[;] and the
   o *throws clause*: exception types declared in the throws clause of the method member.
Additional information:
§ 13.1 of the JLS calls the whole shebang, "the erasure ... of the
qualifying type of the [method] invocation, plus the erasure of the
signature of the method."  This applies to method invocations.
§ 15.12.3 tells us, "If the compile-time declaration for the method
invocation is not void, then the type of the method invocation
expression is the result type specified in the compile-time
declaration."

It was and still is.

If I understand Lew, he is noting that the the JLS uses the term
"type" for return type plus signature and recommending this. I don't
think this usage would be helpful in more generally.

His examples suggest that even in the JLS it's a bit iffy and
unclear. In the second example, we get that a
'type' [of method invocation] is a 'result type'
but that's clearly wrong if the first type is a type in this more
general
sense. An ordered tuple is not the same thing as one element of that
tuple.

Do method invocations not have 'type's in the more general sense? Or
given that this is a type of a method invocation expression -- rather
than of the method itself -- maybe the JLS should have said 'result
type' in both places, though the use of type for an invocation in the
first example suggests that invocations have such a "full" type as
well as methods themselves.


To me the JLS's use of "type" is very easy to confuse with "return
type". I would expect that the phrase
"the type of the method" or "the method type"
would be interpreted by the vast majority of readers as the return
type of the method unless the phrase "type" is defined near where it
is used. By contrast, I'd be far less likely to misapprehend the
phrase "full signature" though I might have to look it up. The phrase
"full type" might be a compromise, though in I suspect most Java
users would think it has something to do with generics.

Since this is a concept that goes well beyond Java, I don't think the
JLS's usage need be the last word, though it should certainly be
considered.

Regards,
Tom McGlynn

 

[Stefan Ram]

Does the JLS also has a term for »int f( int )«, that is,
»signature plus return type«? (A term that is shorter than
»signature plus return type«, of course.)

I am not sure whether the above post (dated 2010-11-30)
was already answered, but in the meantime I found an answer!

(I hope that I do not have missed someone already saying so.)

JLS7 15.12.2p2 calls this a

»descriptor (signature plus return type)«.