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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 7 of 7

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

  1. #1
    Bob Butler Guest

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

    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




  2. #2
    Rob Teixeira Guest

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


    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
    >
    >
    >



  3. #3
    Jonathan Allen Guest

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

    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
    >
    >
    >




  4. #4
    Patrick Steele Guest

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

    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

  5. #5
    Jonathan Allen Guest

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

    > 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




  6. #6
    Kunle Odutola Guest

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


    "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



  7. #7
    Bob Guest

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


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center