Signature. What is it?

[Guest]

Am I correct in thinking that the <signature> of a function is its <syntax>
i.e. the arguments and the order in which they are specified when calling the
function?

 

[Stefan Hoffmann]

hi,

Am I correct in thinking that the <signature> of a function is its <syntax>

Not syntax, but the parameter layout and its returning value type.

i.e. the arguments and the order in which they are specified when calling the
function?

Yes.


mfG
--> stefan <--

 

[Peter Bradley]

hi,

Not syntax, but the parameter layout and its returning value type.

Yes.


mfG
--> stefan <--

Actually, and more specifically, if I understand these things correctly, a
method's signature is comprised of:

* access specifier (public/private/protected)
* static specifier, if it's static
* return type (including void)
* method name
* the ordered list of method parameters

and probably some other things I've forgotten.

i.e. the signature is everything that comes before the opening brace. I
think.


Peter

 

[Oliver Sturm]

Hello Peter,

I'm not sure if there's a scientific definition somewhere, so maybe that
would be interesting. I also agree with you that your definition is pretty
good. But for practical purposes, a signature can be comprised of only a
subset of this information - for example, you can't create a method
overload that differs only in the return type, or the access specifier.
Just something I thought might be worth adding.


Oliver Sturm

 

[Peter K]

Hello Peter,

I'm not sure if there's a scientific definition somewhere, so maybe
that would be interesting. I also agree with you that your definition
is pretty good. But for practical purposes, a signature can be
comprised of only a subset of this information - for example, you
can't create a method overload that differs only in the return type,
or the access specifier. Just something I thought might be worth
adding.

The ECMA C# specification gives a definition of "method signature".

http://www.ecma-international.org/publications/standards/Ecma-334.htm

in section 8.7.3.

"Methods can be overloaded, which means that multiple methods can have
the same name so long as they have unique signatures. The signature of a
method consists of the name of the method and the number, modifiers, and
types of its formal parameters, and the number of generic type
parameters. The signature of a method does not include the return type or
the names of the formal parameters or type parameters."


I don't know if they miss including the "order" of the parameters as
having meaning for the signature?

MyMethod(int, string)
MyMethod(string, int)

 

[Oliver Sturm]

Hello Peter,

I don't know if they miss including the "order" of the parameters as
having meaning for the signature?

MyMethod(int, string)
MyMethod(string, int)

Yes, that's interesting I would also think they should qualify their
use of "signature", for example as "signature for the purpose of this
document" or something like that. Personally I would agree at any time
that the return type of a method is part of what I would call "signature"
- even if it's not relevant for overloading in C#.


Oliver Sturm

 

[Peter Bradley]

Can't argue with that

Don't you just hate it when someone goes and spoils the fun by reading the
docs?

:-D

Peter

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I don't know if they miss including the "order" of the parameters as
having meaning for the signature?

MyMethod(int, string)
MyMethod(string, int)

I believe that is implied. Also that the order of the generic type
parameters is included in the signature.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Hello Peter,


Yes, that's interesting I would also think they should qualify their
use of "signature", for example as "signature for the purpose of this
document" or something like that. Personally I would agree at any time
that the return type of a method is part of what I would call
"signature" - even if it's not relevant for overloading in C#.


Oliver Sturm

The term signature is so common that I don't think it needs to be
specified whenever it's used. It not only identifies the method for
overloading, but also identifies the method whenever you reference it it
any way (e.g. calling it).

If you want to make your own definition of "signature", then it's
actally you who have to specify it every time that you use it.

 

[Oliver Sturm]

Hello Göran,

The term signature is so common that I don't think it needs to be
specified whenever it's used. It not only identifies the method for
overloading, but also identifies the method whenever you reference it it
any way (e.g. calling it).

If you want to make your own definition of "signature", then it's actally
you who have to specify it every time that you use it.

Well, the point was that I don't think I am (making my own definition). I
was agreeing with others that the return type of a method is part of the
method's signature (are you saying you wouldn't agree on that?) and I was
only suggesting that it could add to the precision of that ECMA spec if it
said precisely that the return type is irrelevant when it comes to
overloading.

That said, the spec probably does contain that information somewhere. Once
more, I was only pointing out that the piece of the spec that was quoted
still doesn't completely explain the topic.


Oliver Sturm

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Hello Göran,


Well, the point was that I don't think I am (making my own definition).

Well, that doesn't change that fact that you do.

I was agreeing with others that the return type of a method is part of
the method's signature (are you saying you wouldn't agree on that?)

Yes, I do. The return type is *not* part of the signature.

Although your opinion of what the signature is may be interresting, it's
not relevant to what the signature really is.

and
I was only suggesting that it could add to the precision of that ECMA
spec if it said precisely that the return type is irrelevant when it
comes to overloading.

It says that "multiple methods can have the same name so long as they
have unique signatures" and then goes on defining the term signature and
also making the clarification "The signature of a method does not
include the return type".

Do you really think that it has to be clearer than that?

That said, the spec probably does contain that information somewhere.

Like in the same paragraph?

Once more, I was only pointing out that the piece of the spec that was
quoted still doesn't completely explain the topic.

Yes, it does.

 

[Oliver Sturm]

Hello Göran,

Well, that doesn't change that fact that you do.

No I don't. We're talking about two different things here. The word
"signature" has a meaning outside the world of the C# language definition,
and while I still haven't taken the time to dig up proof, I'm sure that an
example can be found where it includes the return type. There are no
examples there, but the short Wikipedia stub certainly agrees with me:
http://en.wikipedia.org/wiki/Method_signature

Yes, I do. The return type is not part of the signature.

Once again, C# specific. It wasn't my intention to be C# specific in my
replies.

Although your opinion of what the signature is may be interresting, it's
not relevant to what the signature really is.

I was going to react to this comment, but I decided not to.

It says that "multiple methods can have the same name so long as they have
unique signatures" and then goes on defining the term signature and also
making the clarification "The signature of a method does not include the
return type".

Do you really think that it has to be clearer than that?


Like in the same paragraph?

Right, my last post didn't make much sense in that regard. My apologies
for that. I was, and still am, trying to point out that the word
"signature" is not something that has its roots in the C# language
specification. That spec has a certain definition that it uses and it's
just as well that it explains what that definition is.

Yes, it does.

I don't think it does. It explains what a signature is when related to C#,
nothing more and nothing less. Maybe that was the precise question that
the OP was asking - fine, and I think we should be ending this discussion
anyway. But from the beginning I was making the point that there's a
difference between the definition that C# uses and a more generalized
definition one could apply.


Oliver Sturm

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Hello Göran,


No I don't. We're talking about two different things here. The word
"signature" has a meaning outside the world of the C# language
definition, and while I still haven't taken the time to dig up proof,
I'm sure that an example can be found where it includes the return type.
There are no examples there, but the short Wikipedia stub certainly
agrees with me: http://en.wikipedia.org/wiki/Method_signature

Yes, of course the term signature has other meanings in other contexts,
but we are after all in a C# newsgroup.

Once again, C# specific. It wasn't my intention to be C# specific in my
replies.

Then perhaps you should have said that you were going off-topic.

I was going to react to this comment, but I decided not to.


Right, my last post didn't make much sense in that regard. My apologies
for that. I was, and still am, trying to point out that the word
"signature" is not something that has its roots in the C# language
specification. That spec has a certain definition that it uses and it's
just as well that it explains what that definition is.

Yes, as most things the term signature is borrowed from other languages.
I think that it's used in every language there is that supports overloading.

I don't think it does. It explains what a signature is when related to
C#, nothing more and nothing less.

If you mean the topic as "the use of the term signature in computer
history", then the topic is of course not covered completely in the C#
specs. If every aspect of every term would be covered completely as used
outside the scope of the document, the document would be unreadable.

Maybe that was the precise question
that the OP was asking - fine, and I think we should be ending this
discussion anyway. But from the beginning I was making the point that
there's a difference between the definition that C# uses and a more
generalized definition one could apply.

If you want a generalised defintion, then I don't think that it should
be so specific as to either include or exclude the return type. Anyway,
a generalised definition couldn't really be applied to any real
situation, could it?

 

[Jon Skeet [C# MVP]]

Actually, and more specifically, if I understand these things correctly, a
method's signature is comprised of:

* access specifier (public/private/protected)
* static specifier, if it's static
* return type (including void)

None of these are part of the signature.

* method name
Yes.

* the ordered list of method parameters

Yes, and ref vs non-ref is effectively part of a parameter definition,
but there's no distinction betweeen ref and out.


From the C# 2.0 spec:

<quote>
The signature of a method consists of the name of the method, the
number of type parameters, and the type and kind (value, reference, or
output) of each of its formal parameters, considered in the order left
to right. The signature of a method specifically does not include the
return type, parameter names, or type parameter names, nor does it
include the params modifier that can be specified for the right-most
parameter. When a parameter type includes a type parameter of the
method, the ordinal position of the type parameter is used for type
equivalence, not the name of the type parameter.
</quote>

 

[Jon Skeet [C# MVP]]

I believe that is implied. Also that the order of the generic type
parameters is included in the signature.

In the 2.0 spec it's made clearer: "...each of its formal parameters,
considered in the order left to right..."