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

Discussion in 'Java' started by Stefan Ram, Nov 30, 2010.

  1. Stefan Ram

    Stefan Ram Guest

    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, Nov 30, 2010
    #1
    1. Advertising

  2. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >(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.
    Stefan Ram, Nov 30, 2010
    #2
    1. Advertising

  3. On 11/30/2010 05:19 AM, Stefan Ram wrote:
    > 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.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Nov 30, 2010
    #3
  4. "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > 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".
    Mike Schilling, Nov 30, 2010
    #4
  5. Stefan Ram

    Lew Guest

    On Nov 30, 6:41 am, -berlin.de (Stefan Ram) wrote:
    > -berlin.de (Stefan Ram) writes:
    > >(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.


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

    --
    Lew
    Lew, Nov 30, 2010
    #5
  6. Stefan Ram

    Arne Vajhøj Guest

    On 30-11-2010 08:53, Joshua Cranmer wrote:
    > On 11/30/2010 05:19 AM, Stefan Ram wrote:
    >> 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.


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

    :)

    Arne
    Arne Vajhøj, Nov 30, 2010
    #6
  7. Stefan Ram

    Lew Guest

    Stefan Ram wrote:
    >>> 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.)


    Joshua Cranmer wrote:
    >> 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.


    Arne Vajhøj wrote:
    > 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?

    --
    Lew
    Lew, Nov 30, 2010
    #7
  8. On 30-11-2010 18:30, Lew wrote:
    > Stefan Ram wrote:
    >>>> 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.)

    >
    > Joshua Cranmer wrote:
    >>> 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.

    >
    > Arne Vajhøj wrote:
    >> 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?

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


    No.

    Arne
    Arne Vajhøj, Dec 1, 2010
    #8
  9. Stefan Ram

    Roedy Green Guest

    On Tue, 30 Nov 2010 08:53:14 -0500, Joshua Cranmer
    <> wrote, quoted or indirectly quoted someone
    who said :

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


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    In programming, and documenting programs, keep vocabulary consistent and precisely defined! Variation in vocabulary to relieve the tedium is for novels.
    Roedy Green, Dec 1, 2010
    #9
  10. Stefan Ram

    Lew Guest

    Arne Vajhøj wrote:
    >>> I think we should agree here on cljp that this is the correct term
    >>> and push it to the rest of the world!
    >>>
    >>> :)


    Lew wrote:
    >> Or we could agree to use the term already defined in the JLS.


    On 11/30/2010 07:25 PM (US Eastern), Arne Vajhøj wrote:
    > And that was?


    On 11/30/2010 02:27 PM (US Eastern), Lew wrote:
    >> 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
    Lew, Dec 1, 2010
    #10
  11. Stefan Ram

    Lew Guest

    Joshua Cranmer wrote, quoted or indirectly quoted someone who said :
    >> 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.


    Roedy Green wrote:
    > 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!


    --
    Lew
    Lew, Dec 1, 2010
    #11
  12. Stefan Ram

    Roedy Green Guest

    On Tue, 30 Nov 2010 08:53:14 -0500, Joshua Cranmer
    <> wrote, quoted or indirectly quoted someone
    who said :

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


    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    In programming, and documenting programs, keep vocabulary consistent and precisely defined! Variation in vocabulary to relieve the tedium is for novels.
    Roedy Green, Dec 1, 2010
    #12
  13. Stefan Ram

    Tom McGlynn Guest

    On Nov 30, 11:18 pm, Lew <> wrote:
    > Arne Vajhøj wrote:
    > >>> I think we should agree here on cljp that this is the correct term
    > >>> and push it to the rest of the world!

    >
    > >>> :)

    > Lew wrote:
    > >> Or we could agree to use the term already defined in the JLS.

    >
    > On 11/30/2010 07:25 PM (US Eastern), Arne Vajhøj wrote:
    >
    > > And that was?

    >
    > On 11/30/2010 02:27 PM (US Eastern), Lew wrote:
    >
    >
    >
    > >> 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
    Tom McGlynn, Dec 1, 2010
    #13
  14. Stefan Ram

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >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)«.
    Stefan Ram, May 7, 2013
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nikos Mitas
    Replies:
    2
    Views:
    1,006
    Hubble
    Sep 27, 2005
  2. moo moo
    Replies:
    2
    Views:
    370
    Henrique Seganfredo
    Nov 20, 2003
  3. -
    Replies:
    4
    Views:
    310
  4. Replies:
    6
    Views:
    406
    Malcolm Dew-Jones
    Apr 28, 2005
  5. DeMarcus
    Replies:
    49
    Views:
    975
    Jorgen Grahn
    Sep 27, 2011
Loading...

Share This Page