Interface and overloaded functions in visual studio.NET

[sotto]

If i have this Interface:

Public Interface MyInterface
Function test() As Boolean
Function test(ByVal MyVar As String) As Boolean
End Interface

And then i make a

Public Class MyOwnClass
Implements MyInterface
End Class

When i hit [Enter] after the Implements MyInterface
Visual Studio automatically creates

Public Overloads Function test() As Boolean Implements MyInterface.test
End Function

Public Overloads Function test1(ByVal MyVar As String) As Boolean
Implements MyInterface.test
End Function

These two functions for me...

Why does it add the 1 on the overloaded function-name?
Why doesn't it just make a test() and a test(ByVal Myvar As string)
function?
Is there a specific reason for this behaviour?

 

[Armin Zingler]

If i have this Interface:

Public Interface MyInterface
Function test() As Boolean
Function test(ByVal MyVar As String) As Boolean
End Interface

And then i make a

Public Class MyOwnClass
Implements MyInterface
End Class

When i hit [Enter] after the Implements MyInterface
Visual Studio automatically creates

Public Overloads Function test() As Boolean Implements
MyInterface.test End Function

Public Overloads Function test1(ByVal MyVar As String) As Boolean
Implements MyInterface.test
End Function

These two functions for me...

Why does it add the 1 on the overloaded function-name?
Why doesn't it just make a test() and a test(ByVal Myvar As string)
function?
Is there a specific reason for this behaviour?

If you've already got a procedure with the name "test", the IDE uses this
kind of numbering. In this case, it wouldn't be necessary, so you're right.
I'd post it again in microsoft.public.vsnet.ide.

 

[Herfried K. Wagner [MVP]]

If i have this Interface:

Public Interface MyInterface
Function test() As Boolean
Function test(ByVal MyVar As String) As Boolean
End Interface

And then i make a

Public Class MyOwnClass
Implements MyInterface
End Class

When i hit [Enter] after the Implements MyInterface
Visual Studio automatically creates

Public Overloads Function test() As Boolean Implements MyInterface.test
End Function

Public Overloads Function test1(ByVal MyVar As String) As Boolean
Implements MyInterface.test

End Function

These two functions for me...

Why does it add the 1 on the overloaded function-name?
Why doesn't it just make a test() and a test(ByVal Myvar As string)
function?

Is there a specific reason for this behaviour?

I currently don't have VS.NET 2003 here, but if it names it with an "1"
at the end of the name it is maybe a bug.

 

[Trev Hunter]

I currently don't have VS.NET 2003 here, but if it

names it with an "1" at the end of the name it is maybe a bug.

I use VS2003 and it does name overloaded interface methods with an number
suffix.

e.g.

Test()
Test1()
Test2()

etc.

Trev.

If i have this Interface:

Public Interface MyInterface
Function test() As Boolean
Function test(ByVal MyVar As String) As Boolean
End Interface

And then i make a

Public Class MyOwnClass
Implements MyInterface
End Class

When i hit [Enter] after the Implements MyInterface
Visual Studio automatically creates

Public Overloads Function test() As Boolean Implements MyInterface.test
End Function

Public Overloads Function test1(ByVal MyVar As String) As Boolean
Implements MyInterface.test

End Function

These two functions for me...

Why does it add the 1 on the overloaded function-name?
Why doesn't it just make a test() and a test(ByVal Myvar As string)
function?

Is there a specific reason for this behaviour?

I currently don't have VS.NET 2003 here, but if it names it with an "1"
at the end of the name it is maybe a bug.

 

[Philip Rieck]

VS.net uses "proc", "proc1", "proc2" .... type naming when generating
function names for you. If it generates "proc", but that name already
exists, then it will try "proc1". If that exists, it will try "proc2", and
so on...

While the generator COULD use method overloads, overloading a method only
makes sense if the functions are closely related. VS.NET really doesn't
know if they're related or not, so it names them uniquely. This naming is
applied in all cases, even when using the same name isn't an issue.

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,
As Trev stated, it "numbers" the members when they are overloaded, I suspect
for the reason Armin cited.

The numbering partially makes senses when the class had a Test function with
a different return type before I added the interface! I'm sure numbering is
the "easy way" to implement it. ;-)

However! more oft then not, I do not want the methods numbered, I either
want implicitly or explicit interface implementation (to borrow the C#
term).

' implicit interface implementation

Public Function test() As String
End Function

' explicit interface implementation
Also in this context the Overloads normally is not needed, I'm suspect its
injected incase I am implementing the interface in a class that already has
a Test method inherited from a base class.

Just a thought
Jay

If i have this Interface:

Public Interface MyInterface
Function test() As Boolean
Function test(ByVal MyVar As String) As Boolean
End Interface

And then i make a

Public Class MyOwnClass
Implements MyInterface
End Class

When i hit [Enter] after the Implements MyInterface
Visual Studio automatically creates

Public Overloads Function test() As Boolean Implements MyInterface.test
End Function

Public Overloads Function test1(ByVal MyVar As String) As Boolean
Implements MyInterface.test

End Function

These two functions for me...

Why does it add the 1 on the overloaded function-name?
Why doesn't it just make a test() and a test(ByVal Myvar As string)
function?

Is there a specific reason for this behaviour?

I currently don't have VS.NET 2003 here, but if it names it with an "1"
at the end of the name it is maybe a bug.

 

[Herfried K. Wagner [MVP]]

The numbering partially makes senses when the class had a Test function with
a different return type before I added the interface! I'm sure numbering is
the "easy way" to implement it. ;-)

Seems to be a "quick and dirty" solution...

;-)

However! more oft then not, I do not want the methods numbered, I either
want implicitly or explicit interface implementation (to borrow the C#
term).

I don't like numbered methods too.

 

[Jay B. Harlow [MVP - Outlook]]

Herfried,
Aren't "easy way" and "quick and dirty" synonyms?

)

Jay

 

[Cor]

Hi Jay B,

I hope you don't mind I answer also?

Aren't "easy way" and "quick and dirty" synonyms?

I think not, they are opposites in my eyes.

Keep it simple is not only a term I often use.

If you cannot "Keep it simple", the "quick and dirty" way is mostly the bad
solution.
(About that we do not have to argue).

Just a thought,

Cor

 

[Trev Hunter]

Aren't "easy way" and "quick and dirty" synonyms?

"easy way", "quick and dirty" and "quick and beautiful" are in the eyes of
the beholder

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
What's that saying about if you have to explain a joke? :-|


Joking aside: I hope you realize that "easy way" is not necessary "keep it
simple", in the context I was using it "easy way" is the path of least
resistance, the quick way for the Microsoft employee. The "quick & ..."
way... At least from my perspective & understanding of compilers.

Also "keep it simple" for who the Microsoft employee or for the target
audience the non-Microsoft developer who uses VB.NET?

As Trev stated its in the "eye of the beholder", and I'm adding its a matter
of perspective. Either Microsoft the developer of the language or Us the
consumer of the language...

Think about, in some cases, how much effort you need to code, to get
something "real simple" for the user of your program. Or when you take the
easy programming route, how much work more work the user of your program
has.

Note I am not disagreeing you with, I am just trying to point out the
perspective I used in the statement.

Just a thought
Jay

 

[Cor]

Hi Jay,

You know we agree, but I have seen to much solutions on the difficult way,
which did not add anything to what you are saying (and as you know I agree).

I thought, we both think the same in this matters, but I brought it in to
tell that the "difficult" way is not always the best solution.

Quick and dirty is in my opinion only allowed as a patch when there is
really nothing else, mostly it never changes and gives you trouble on then
next version of the OS or the compiler.

(Was a discussion also in this newsgroup when somebody said, never fix it if
is not broken, that I also not agreed, you have to do maintanance if the
economic cost of something has reached the break even point)

That is what I think about it.

To recapitulate the difficult way is not always the best way, quick and
dirty is always the worse way.

If you do not disagree, and I think so, no need to answer.

Cor