By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,572 Members | 1,516 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,572 IT Pros & Developers. It's quick & easy.

Interface and overloaded functions in visual studio.NET

P: n/a
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?
Nov 20 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"sotto" <ju**@sotto.invalid> schrieb
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.
--
Armin

http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

Nov 20 '05 #2

P: n/a
* sotto <ju**@sotto.invalid> scripsit:
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]
<http://www.mvps.org/dotnet>
Nov 20 '05 #3

P: n/a
> 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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ez*************@TK2MSFTNGP10.phx.gbl... * sotto <ju**@sotto.invalid> scripsit:
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]
<http://www.mvps.org/dotnet>

Nov 20 '05 #4

P: n/a
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.
"sotto" <ju**@sotto.invalid> wrote in message
news:G9*********************@hestia.telenet-ops.be...
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?

Nov 20 '05 #5

P: n/a
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 Boolean Implements MyInterface.test
End Function

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

Public Function test() As String
End Function

' explicit interface implementation Private Function MyInterface_test() As Boolean Implements MyInterface.test End Function

Private Function MyInterface_test(ByVal MyVar As String) As Boolean
Implements MyInterface.test

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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ez*************@TK2MSFTNGP10.phx.gbl... * sotto <ju**@sotto.invalid> scripsit:
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]
<http://www.mvps.org/dotnet>

Nov 20 '05 #6

P: n/a
* "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:
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.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>
Nov 20 '05 #7

P: n/a
Herfried,
Aren't "easy way" and "quick and dirty" synonyms?

:-))

Jay

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:bu************@ID-208219.news.uni-berlin.de...
* "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> scripsit:
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.

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Nov 20 '05 #8

P: n/a
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
Nov 20 '05 #9

P: n/a
> 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 ;)
Nov 20 '05 #10

P: n/a
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" <no*@non.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
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

Nov 20 '05 #11

P: n/a
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
Nov 20 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.