I should add to my previous day's post, that the likely hood (at least in my
code) of "overloading" an method is greater then "overloading" a type.
For example there would probably be only a single "Debug" type in my
application (solution) (across all namespaces), where as there maybe many
"Write" methods unique to any numbers of types. (for example Equals,
ToString). <sidenote> I use namespaces more for organization then to allow
me to have 2 types with the same name in different namespaces, as chances
are if they have the same name they have the same function... However this
is not always true, for example the Person domain object and the Person web
page or Person windows form, although I normally use Person, PersonPage &
PersonForm for the types themselves...</sidenote>
Hence qualifying a method with a type name (Debug.WriteLine) is generally
more beneficial then qualifying a type name with a namespace
(System.Diagnostics.Debug)... The Imports System.Diagnostics (at either the
file or project level) simply saves typing System.Diagnostics every place I
need to use the Debug type.
While the qualifying Debug ensures that I can introduce a WriteLine method
in my type without it interfering with calling the Debug.WriteLine method...
For a "better" example of the problems the implicit import causes try
calling VB.Left (Microsoft.VisualBasic.Strings.Left) function in a form.
Because Form has a Left property you cannot call the Left function
unqualified... <sidenote>This is one place where I will use an import alias.
"Imports VB = Microsoft.VisualBasic" which allows me to call
VB.Left...</sidenote>
--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley -
http://www.tsbradley.net
"dgk" <dg*@somewhere.com> wrote in message
news:cn********************************@4ax.com...
| On Wed, 22 Mar 2006 07:06:34 -0600, "Jay B. Harlow [MVP - Outlook]"
| <Ja************@tsbradley.net> wrote:
|
| >Mythran,
| >| Well, in VB, you can...use Module...which, in turn, is a static class
:)
| >Unfortunately a Module has the added "annoyance"/"feature" of being
| >implicitly imported, where as C#'s static class needs to be explicitly
| >qualified.
| >
| >If you like the convenience of implicit imported, then using a Module for
a
| >static class is good, however I find needing to qualify the identifiers
of a
| >static class to be more beneficial. As I then know where the identifier
is
| >coming from.
| >
| >For example:
| >
| > Debug.WriteLine(...)
| >
| >You know that the WriteLine is part of the Debug class, rather then:
| >
| > WriteLine(...)
| >
| >You don't know if WriteLine is part of System.Diagnostics.Debug,
| >System.Console, a base class, a Module, or something else...
| >
| >I normally reserve Module's for truly global identifiers, such as math
| >functions. I see some benefit in having System.Math being a module,
however
| >its easy enough to import System.Math to gain unqualified access to its
| >identifiers...
|
| Then using Imports is bad because you don't know where the
| object/method/whatever is actually coming from. And that's true.
| Whenever I start playing with someone else's code I start commenting
| out the Imports. I love seeing those little blue squigglies appear.