Can I use an asterisk in the "Imports" statement?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In Java I can use, for example, " Imports java.util.* ". Can I use, for
example, " Imports System.* " instead of several different "Imports"
statements? Thank you. David
 
pcnerd said:
In Java I can use, for example, " Imports java.util.* ". Can I use, for
example, " Imports System.* " instead of several different "Imports"
statements?
Click to expand...

Simply use 'Imports System'.
 
Well, needless to say, I'm confused! One reply is "No, you can't. I tried."
& the other is "Simply use 'Imports System' "!

So, I suppose that if I use "Imports System" , it will probably be a pretty
big file.

I wonder why I've gotten 2 different answers.

Thank you. David
 
The answer is NO

Using 'Imports System' will not give you access to
'System.Data.SqlClient'
If you just import System, you will only get things in the System
namespace such as 'System.Int32' and 'System.Type' etc.
 
Steven Nagy said:
The answer is NO

Using 'Imports System' will not give you access to
'System.Data.SqlClient'
If you just import System, you will only get things in the System
namespace such as 'System.Int32' and 'System.Type' etc.
Click to expand...

That's true, but it would be rather useless to import all subnamespaces of a
namespace. Importing using the asterisk in Java will import the types
contained in the package, but it won't import other packages.
 
pcnerd said:
So, I suppose that if I use "Imports System" , it will probably be a pretty
big file.
Click to expand...

This comment suggests you might have a misconception about Imports in
VB.NET, because it is the same word as a Java keyword. Now, my Java
experience is pretty small, but am I right in thinking that in Java you
want to import only the minimum you need to, because importing actually
does something to the produced executable? Well, in VB.NET, Imports is
*entirely* syntactic sugar - all it does is allow us to use the names
of things from our References without fully qualifying them. As the
docs put it: "Importing does not take the place of setting a reference.
It only removes the need to qualify names that are already available to
your project."

For example, once we reference, say, System.dll, everything in there is
available to us whether we use Imports System or not; all the Imports
line does is allow us to refer to System.Uri as simply 'Uri' in our
code.

Note that many commonly-used namespaces are imported automatically in
newly-created projects, at the project level, so we often don't need
any Imports statements in individual files.


Of course, if you knew all this already, great! :)
 
pcnerd said:
Well, needless to say, I'm confused! One reply is "No, you can't. I tried."
& the other is "Simply use 'Imports System' "!

So, I suppose that if I use "Imports System" , it will probably be a pretty
big file.
Click to expand...

The resulting file will be /no bigger/, regardless of how many Imports
statements you use, because the Imports statement doesn't do what you
think it does.

It does NOT give your application "access" to anything it didn't have
before. That's does by adding References to other assemblies and no;
the Referenced assemblies are not compiled into your finished program;
they become run-time dependencies.

Imports /only/ allows you, in your code, to /type less/, as in

(without Imports)
Console.Writeline( _
System.Reflection.MethodBase.GetCurrentMethod().Name _
)

or (with Imports)

Imports System.Reflection.MethodBase
.. . .
Console.Writeline( _
GetCurrentMethod().Name _
)

When the code gets compiled, the fully qualified names get used
regardless of what you typed, so the size of your executable is unaffected.

HTH,
Phill W.
 
Back
Top