Imports A.B.C vs Imports ABC=A.B.C

[Bob Butler]

In VB I frequently used code like "Dim RS As ADODB.RecordSet" rather than
"Dim RS As RecordSet" so that there was no question over what library the
object comes from and no problems if I needed to add another library that
exposes a RecordSet object. One thing that bothers me looking at most of
the VB.Net samples I see is that the libraries are generally mentioned once
in an Imports statement and then just the simple object names are used
throughout the code. For commonly used, "well known" objects this may not
be a significant problem but I'm wondering how others view the potential
standard of using something like:

Imports SDS=System.DirectoryServices
....
Dim SR as SDS.SearchResult

as opposed to:

Imports System.DirectoryServices
....
Dim SR As SearchResult

or, as another example:

Imports W32=Microsoft.Win32
Dim k As W32.RegistryKey

[Rob Teixeira]

Qualifying a class name is always a good idea. The only issue is that in .NET,
namespaces can get very deep. So you might end up with:

Dim C As System.Runtime.Remoting.Channels.IChannel

So I can Import a namespace to allow for short-cutting your qualifying statements.

Imports System.Runtime.Remoting.Channels
- - -
Dim C As IChannel

Aliasing a namespace is designed to specifically resolve problems with conflicting
identifiers, which is what you are discussing here with [alias = namespace].

Theoretically, you'd only have to use if you get a conflict, but there's
nothing wrong with making it a standard for your work environment either.
I'm very much in favor of faulting on the safe side, so I'll qualify as much
as possible (mostly for documentation reasons), and if the namespaces get
too deep, I'll use aliasing.

-Rob

"Bob Butler" <butlerbob@earthlink.net> wrote:
>In VB I frequently used code like "Dim RS As ADODB.RecordSet" rather than
>"Dim RS As RecordSet" so that there was no question over what library the
>object comes from and no problems if I needed to add another library that
>exposes a RecordSet object. One thing that bothers me looking at most of
>the VB.Net samples I see is that the libraries are generally mentioned once
>in an Imports statement and then just the simple object names are used
>throughout the code. For commonly used, "well known" objects this may not
>be a significant problem but I'm wondering how others view the potential
>standard of using something like:
>
>Imports SDS=System.DirectoryServices
>....
>Dim SR as SDS.SearchResult
>
>as opposed to:
>
>Imports System.DirectoryServices
>....
>Dim SR As SearchResult
>
>or, as another example:
>
>Imports W32=Microsoft.Win32
>Dim k As W32.RegistryKey
>
>
>

[Jonathan Allen]

I think two-part names should be enough for most situations. For instance
....
Dim SR As DirectoryServices.SearchResult

As far as using an alias, it would have to a company standard. Either we all
use...
Imports W32=Microsoft.Win32
....or none of us do. Otherwise we will waste too much time trying to figure
out each other's abbreviations.


--
Jonathan Allen


"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3b731c0c@news.devx.com...
> In VB I frequently used code like "Dim RS As ADODB.RecordSet" rather than
> "Dim RS As RecordSet" so that there was no question over what library the
> object comes from and no problems if I needed to add another library that
> exposes a RecordSet object. One thing that bothers me looking at most of
> the VB.Net samples I see is that the libraries are generally mentioned
once
> in an Imports statement and then just the simple object names are used
> throughout the code. For commonly used, "well known" objects this may not
> be a significant problem but I'm wondering how others view the potential
> standard of using something like:
>
> Imports SDS=System.DirectoryServices
> ...
> Dim SR as SDS.SearchResult
>
> as opposed to:
>
> Imports System.DirectoryServices
> ...
> Dim SR As SearchResult
>
> or, as another example:
>
> Imports W32=Microsoft.Win32
> Dim k As W32.RegistryKey
>
>
>

[Patrick Steele]

In article <3b731c0c@news.devx.com> (from Bob Butler
<butlerbob@earthlink.net>),
> ...I'm wondering how others view the potential
> standard of using something like:
>
> Imports SDS=System.DirectoryServices
> ...
> Dim SR as SDS.SearchResult
>
> as opposed to:
>
> Imports System.DirectoryServices
> ...
> Dim SR As SearchResult
>
> or, as another example:
>
> Imports W32=Microsoft.Win32
> Dim k As W32.RegistryKey

I'm also wondering how this affects .NET if (when) it goes cross-
platform. I was thinking that an x-windows version of a forms package
would contain the same classes as System.Windows.Forms (Button class,
Checkbox class, ComboBox class, etc...). But would they (the makers of
the x-windows assembly) call it "System.Windows.Forms"? Should they?
Is that written in stone?

Suppose I have code that looks like this:

dim m_OK as New System.Windows.Forms.Button()

That's not going to port very easily to the x-windows forms package.
But, if I do this:

#if WIN = True then
imports System.Windows.Forms
#end if

#if LINUX = True then
imports System.Linux.XForms
#end if

dim m_OK as New Button()

My code becomes much more portable. Anyone else have any thoughts on
this?

--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect
Image Process Design

[Jonathan Allen]

> My code becomes much more portable. Anyone else have any thoughts on
> this?

I think it would be better to build a separate GUI for each OS. As a Windows
user, I don't want a GUI that works like a XWindows or Macintosh
application. And I am sure that XWindows and Macintosh users don't want
programs that behave like Windows.

--
Jonathan Allen


"Patrick Steele" <psteele@ipdsolution.com_> wrote in message
news:MPG.15ddb646ee36f4d7989821@news.devx.com...
> In article <3b731c0c@news.devx.com> (from Bob Butler
> <butlerbob@earthlink.net>),
> > ...I'm wondering how others view the potential
> > standard of using something like:
> >
> > Imports SDS=System.DirectoryServices
> > ...
> > Dim SR as SDS.SearchResult
> >
> > as opposed to:
> >
> > Imports System.DirectoryServices
> > ...
> > Dim SR As SearchResult
> >
> > or, as another example:
> >
> > Imports W32=Microsoft.Win32
> > Dim k As W32.RegistryKey
>
> I'm also wondering how this affects .NET if (when) it goes cross-
> platform. I was thinking that an x-windows version of a forms package
> would contain the same classes as System.Windows.Forms (Button class,
> Checkbox class, ComboBox class, etc...). But would they (the makers of
> the x-windows assembly) call it "System.Windows.Forms"? Should they?
> Is that written in stone?
>
> Suppose I have code that looks like this:
>
> dim m_OK as New System.Windows.Forms.Button()
>
> That's not going to port very easily to the x-windows forms package.
> But, if I do this:
>
> #if WIN = True then
> imports System.Windows.Forms
> #end if
>
> #if LINUX = True then
> imports System.Linux.XForms
> #end if
>
> dim m_OK as New Button()
>
> My code becomes much more portable. Anyone else have any thoughts on
> this?
>
> --
> Patrick Steele
> (psteele@ipdsolution.com)
> Lead Software Architect
> Image Process Design

[Kunle Odutola]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3b7423d9@news.devx.com...
> > My code becomes much more portable. Anyone else have any thoughts on
> > this?
>
> I think it would be better to build a separate GUI for each OS. As a
Windows
> user, I don't want a GUI that works like a XWindows or Macintosh
> application. And I am sure that XWindows and Macintosh users don't want
> programs that behave like Windows.

Defeats the point of having a portable development/runtime platform. I can
live with a platform-dependent native GUI library as well as a
cross-platform library....

Kunle

[Bob]

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3b7423d9@news.devx.com...
> > My code becomes much more portable. Anyone else have any thoughts on
> > this?
>
> I think it would be better to build a separate GUI for each OS. As a
Windows
> user, I don't want a GUI that works like a XWindows or Macintosh
> application. And I am sure that XWindows and Macintosh users don't want
> programs that behave like Windows.
>
> --
> Jonathan Allen
>
As a Windows user, I'd LOVE a GUI that works like an XWindows application.

Bob