Include Statement

[Mike]

Maybe I missed this because I can't find it, but is there and "include
sourcefile" statement in VB.NET? example

'MainProgram.vb

imports system

module module1

#include "some_common_stuff.vb"
#include "useful_classes.vb"

sub main()
end end

end module

I mean, this is standard stuff in the other .NET languages? No?

 

[Herfried K. Wagner [MVP]]

Maybe I missed this because I can't find it, but is there and "include
sourcefile" statement in VB.NET? example

'MainProgram.vb

imports system

module module1

#include "some_common_stuff.vb"
#include "useful_classes.vb"

sub main()
end end

end module

I mean, this is standard stuff in the other .NET languages? No?

No, there isn't, because it's not necessary in languages like VB and C#.
Types defined in another source file belonging to the project can be
accessed *directly* if the namespace they reside in is imported and the
types' visibility settings grant permission to access the types/members. No
need for forward declarations!

 

[Mike]

No, there isn't, because it's not necessary in languages like VB and C#.

Who says? Gawd, I hate this closed indset.

Types defined in another source file belonging to the project can be
accessed *directly* if the namespace they reside in is imported and the
types' visibility settings grant permission to access the
types/members. No need for forward declarations!

So why do other .NET, like C++ languages support a simple include
concept? Including VB ASPX files?

I mean, this is yet another case where VB.NET attempts to inherit
standard compiler concepts, but fails to do go all the way, only does
for a few things. For example, existing compiler directive

#const USE_VERSION = 1

#if USE_VERSION = 1 then
some v1 code
#elseif USE_VERSION = 2 then
some v2 code
#else then
#error "USE_VERSION not defined"
#end if

Very powerful ideas for programmers. Don't tell me it "isn't
necessary." If VB.NET support these compiler directives, there is no
reason why it couldn't do #include. Adding a standard #include concept
isn't going to change anything regarding name spaces and that wouldn't
be the purpose, but in fact, it could very useful in quickly creating
new namespaces out of include files

namespace MyNewNameSpace
#include "class_dispose.vb"
#include "class_music.vb"
#include "class_whatever.vb"
end namespace

etc.

Its not a hard idea to understand.

A replacement VBC.EXE pre-processor to handle this is possible with
CodeDOM.

Anyway, thanks for confirming its not available.

--

 

[Armin Zingler]

Who says? Gawd, I hate this closed indset.

I say it (too).

So why do other .NET, like C++ languages support a simple include
concept? Including VB ASPX files?

Why do other .NET languages like C# do not support #include? Because
it's not required. C++ has it because it's not a pure managed language and
because the concept has not been changed for the CLI part in the C++
compiler. That's one reason why it's so horrible to write C++/CLI
applications (-> forward declarations).

I mean, this is yet another case where VB.NET attempts to inherit
standard compiler concepts, but fails to do go all the way, only does
for a few things. For example, existing compiler directive

#const USE_VERSION = 1

#if USE_VERSION = 1 then
some v1 code
#elseif USE_VERSION = 2 then
some v2 code
#else then
#error "USE_VERSION not defined"
#end if

Very powerful ideas for programmers. Don't tell me it "isn't
necessary." If VB.NET support these compiler directives, there is no
reason why it couldn't do #include.

You're saying there are compiler directives so there must be #include, too?
I don't see the relation. The one is useful, the other is not.

Adding a standard #include concept
isn't going to change anything regarding name spaces and that wouldn't
be the purpose, but in fact, it could very useful in quickly creating
new namespaces out of include files

namespace MyNewNameSpace
#include "class_dispose.vb"
#include "class_music.vb"
#include "class_whatever.vb"
end namespace

etc.

Its not a hard idea to understand.

For me it's hard. Why not just reference the assembly containing these
classes? I never reuse "lines of code", I only reuse classes.


Armin

 

[sloan]

The (simple) Factory pattern is the OO way and probably solution to your
need.

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!126.entry


//Quote // Don't tell me it "isn't > necessary."//End Quote

That is a bold and somewhat arrogant imperative statement you made.
But for the record, it is not necessary. How do I know? Because they don't
exist in vb.net.

A proper interface (or abstract class) with multiple (and exchangable)
concretes is a much better method.


The strategy design pattern is another potential method for what you need
is.
http://www.dofactory.com/Patterns/PatternStrategy.aspx


I would pick up some Design Pattern books. Design patterns are at a
"higher" level than any particuliar language.
If the book is java, smarttalk, c#, or whatever, you can learn something
from the ideas.

Head First Design Patterns is one of the usual suggestions as a starter
book.

 

[Mike]

You're saying there are compiler directives so there must be #include,
too? I don't see the relation. The one is useful, the other is not.

I'm not convinced. There is no difference in the usefulness of the
above being this:

#const USE_VERSION = 1

#if USE_VERSION = 1 then
#include "version1.inc"
#elseif USE_VERSION = 2 then
#include "version2.inc"
#else then
#error "USE_VERSION not defined"
#end if

There are MILLION programmers who do feel this is very useful. I
wouldn't be surprise as VB.NET gets more experience, a future compiler
would add more pre-processors technology - just like all the languages
had evolved. I won't be surprise as VB.NET gets more and more C/C++
methods, #include and other concepts will be added to the compiler.

To say it has no usefulness, just because you can't see it, is
ludicrous. Again, ASPX files has include concepts too.

For me it's hard. Why not just reference the assembly containing these
classes? I never reuse "lines of code", I only reuse classes.

A include file can be class, but fair enough. But that just a matter
of lack of wide development experience, especially across different
languages and especially in production where such ideas are par for
the course.

---

 

[Mike]

Don't confuse ASSEMBLIES with INCLUDEs of code. Two different things.

--

 

[Herfried K. Wagner [MVP]]

Who says? Gawd, I hate this closed indset.

The VB compiler works in an other way than C/C++ compilers, for example.

Typically includes have been used in C/C++ to make functionality defined in
another file available in another file (I do not use C/C++ terminology here
because I am not sure if you are familiar with C/C++). This is done
automatically by the VB compiler, so there is no need to do it manually.

So why do other .NET, like C++ languages support a simple include concept?
Including VB ASPX files?

The C++ compiler doesn't do all the work for you which the VB compiler does.
ASP.NET applications differ in structure from the typical project which is
compiled into one binary file.

I mean, this is yet another case where VB.NET attempts to inherit standard
compiler concepts, but fails to do go all the way, only does for a few
things. For example, existing compiler directive

#const USE_VERSION = 1

#if USE_VERSION = 1 then
some v1 code
#elseif USE_VERSION = 2 then
some v2 code
#else then
#error "USE_VERSION not defined"
#end if

Very powerful ideas for programmers. Don't tell me it "isn't necessary."

This is supported in VB.NET because it makes perfect sense even in VB.NET!

If VB.NET support these compiler directives, there is no reason why it
couldn't do #include.

I already mentioned the reason why it is not necessary. In C/C++ '#include'
is the typical way to make information from one file available to another
one. In C/C++ you even have to write forward declarations and so on because
the help the compiler provides in this regard is rather limited compared to
the work the VB compiler does.

BTW, the '#include' concept of C/C++ is rather low-level and not very
comfortable to use.

Adding a standard #include concept isn't going to change anything
regarding name spaces and that wouldn't be the purpose, but in fact, it
could very useful in quickly creating new namespaces out of include files

namespace MyNewNameSpace
#include "class_dispose.vb"
#include "class_music.vb"
#include "class_whatever.vb"
end namespace

Just add the namespace declaration on each of the files. No need to use
text-based inclusion of other files. Code duplication, which was one of the
top reasons for using '#include' in C/C++ isn't required and it would not
work in VB.

 

[Herfried K. Wagner [MVP]]

Why do other .NET languages like C# do not support #include? Because
it's not required. C++ has it because it's not a pure managed language and
because the concept has not been changed for the CLI part in the C++
compiler.

Just to make this more clear: That's basically not a feature of managed
languages, it's just a language/compiler feature of certain programming
languages which are not necessarily .NET-based (Classic VB, Java, ...).
Classic VB didn't require forward declataions too because the compiler was
able to search for the declarations automatically.

 

[Cor Ligthert[MVP]]

Armin,

What is the sense of this discussion.

We see this still in scripting languages, but it is not even more in ASPX.

I really miss the sense of this in a discussion about VB or in fact any
program language from this millennium.

Is the next topic the Var?

Cor

 

[Mike]

The VB compiler works in an other way than C/C++ compilers, for example.

Typically includes have been used in C/C++ to make functionality defined
in another file available in another file (I do not use C/C++
terminology here because I am not sure if you are familiar with C/C++).

What terminology are you speaking of? I'm a veteran of 21+ different
languages. VB.NET, C# and C++/CLR will be my 22, 23, 24. Use ANY
references if you like.

This is done automatically by the VB compiler, so there is no need to do
it manually.

Do what? IMO, you are limiting your mind to one way of doing things.
A silly idea that "includes" are not useful is that same silly idea
you said arrays are not useful in MOST cases.

If you are an MVP, you are suppose to be more open minded about
general programming ideas.

Remember it is VB.NET that is learning from C/C++ concepts. If it can
learn how to do inclusive increments,

string += string

and it learn compiler directives, it can also learn do a #include idea.

The C++ compiler doesn't do all the work for you which the VB compiler
does.

huh? Like what?

Also, lets distinguish VB.NET as oppose VB. Different animals.

ASP.NET applications differ in structure from the typical project
which is compiled into one binary file.

What does that have to do with Include ideas?

This is supported in VB.NET because it makes perfect sense even in VB.NET!

And this does not?

#const USE_VERSION = 1

#if USE_VERSION = 1 then
#include "version1.inc"
#elseif USE_VERSION = 2 then
#include "version2.inc"
#else then
#error "USE_VERSION not defined"
#end if

I already mentioned the reason why it is not necessary.

No, you did not.

In C/C++
'#include' is the typical way to make information from one file
available to another one.

And why isn't that useful for VB.NET

In C/C++ you even have to write forward
declarations

Hogwash. Not related at all.

and so on because the help the compiler provides in this
regard is rather limited compared to the work the VB compiler does.

Man, and you are an MVP?

BTW, the '#include' concept of C/C++ is rather low-level and not very
comfortable to use.

Again, outrageous statements.

Just add the namespace declaration on each of the files.

What if I don't want to? But even then. Its besides the point.

No need to use
text-based inclusion of other files. Code duplication, which was one of
the top reasons for using '#include' in C/C++ isn't required and it
would not work in VB.

But its ok for ASPX?

Code Duplication? How about library references? How about the idea
of single sourcing?

You can have class files and a main

' file: class1.vb
class MyClass1
..
end class

' file: class2.vb
class MyClass2
..
end class

' file: main.vb
Module Module1
Sub Main()
End Sub
End Module

with no namespace requirements and compile it like

vbc main.vb class1.vb class2.vb

which is basically the same ideas of having:

#include "class1.vb"
#include "class2.vb"
Module Module1
Sub Main()
End Sub
End Module

Please, I think you mind is molded about GUI IDE development and now
power programming console development methods. Its a side note, but
the IDE does blind people of programming methods.

--

 

[Mike]

Armin,

What is the sense of this discussion.

We see this still in scripting languages, but it is not even more in ASPX.

I really miss the sense of this in a discussion about VB or in fact any
program language from this millennium.

Is the next topic the Var?

Cor

I'm not privy to your experience here, but the way I see it the more
VB.NET or should we call it VB++ add more and more traditional
concepts and constructs from C/C++ languages, then you shouldn't be
surprise to see these types of discussions emerge. It isn't like its
going to go away. VB.NET is evolving with each version with MORE and
MORE native language features. In fact, I am kinda liking VB.NET.

Its like the other day, I was concatenating some strings and just for
shits and grins, I said "let me try.."

dim s as string = ""
s += "asdasda"
s += "asdasda"
s += "asdasda"
s += "asdasda"

and to my surprise it worked. I also tried C/C++ initializer ideas

dim foo() as string = {}

and it worked and so on. Different idea from an include, but even
there where I use compiler directives in my exploratory development,
it was happily surprise the VB.NET is going C/C++!!! <g>

I expect #include to be added. In fact, I am going sending some email
so my MS contacts about it

--

 

[Family Tree Mike]

Maybe I missed this because I can't find it, but is there and "include
sourcefile" statement in VB.NET? example

'MainProgram.vb

imports system

module module1

#include "some_common_stuff.vb"
#include "useful_classes.vb"

sub main()
end end

end module

I mean, this is standard stuff in the other .NET languages? No?

I don't see how your example would have any benefit above simply adding
some_common_stuff.vb and useful_classes.vb to the project. What is it that
this would add as I'm not seeing any visibility change implied.

Perhaps a useful "include use case" is the following:

#include "StandardImports.inc"
public class Foo
end class

where StandardImports.inc lists the imports you want. I don't think this
ends up saving much typing however as I just use the refactor tools to add
the imports as I encounter the need for them.

Mike

 

[Stephany Young]

Armin Zingler wrote:

There are MILLION programmers who do feel this is very useful. I wouldn't
be surprise as VB.NET gets more experience, a future compiler would add
more pre-processors technology - just like all the languages had evolved.
I won't be surprise as VB.NET gets more and more C/C++ methods, #include
and other concepts will be added to the compiler.

<snip>

Name them!

 

[Mike]

<snip>

Name them!

Just about every developer outside of VB world. Plus the designers of
VB themselves! <g>

Besides I am very 100% confident if VB supported include concept, you
would used it too.

You guys need to stop being anal about something you don't have and
come up with silly justifications why this world is BETTER because
of it!

--

 

[Herfried K. Wagner [MVP]]

Do what? IMO, you are limiting your mind to one way of doing things. A
silly idea that "includes" are not useful is that same silly idea you said
arrays are not useful in MOST cases.

If you would not quote my post incompletely the answer to your question
would already be included.

Remember it is VB.NET that is learning from C/C++ concepts. If it can
learn how to do inclusive increments,

string += string

and it learn compiler directives, it can also learn do a #include idea.

Well, it could even learn inline assembler, couldn't it?

In programming language design the language designer makes a decision
between different concepts which can be used to achieve a certain goal,
based on an evaluation of these concepts. The '#include' concept is a
rather low-level concept. Thus it's not present in many "younger"
programming languages like Classic VB, Java, and .NET.

Interestingly the demand for this feature is practically non-existent,
basically for the reason that there are now other ways to achieve the same
goal as with the rather limited text-based '#include' approach.

huh? Like what?

Re-read what I have written and you'll find the answer there. Hint:
Looking for declarations. I really wonder if I'll see a thread here about
re-introduction of forward declarations in the VB group, for the reason of
adding well-known C/C++ concepts to VB. (BTW, I am aware that '#include' is
used for additional purposes in C/C++).

Also, lets distinguish VB.NET as oppose VB. Different animals.

My terminology:

VB.NET = VB.
Classic VB = VB1 to VB6, VBA

What does that have to do with Include ideas?

It was /you/ who mentioned ASPX files!

And this does not?

#const USE_VERSION = 1

#if USE_VERSION = 1 then
#include "version1.inc"
#elseif USE_VERSION = 2 then
#include "version2.inc"
#else then
#error "USE_VERSION not defined"
#end if

Could you show a real world sample?

No, you did not.

I did, but you didn't (want to?) read it.

And why isn't that useful for VB.NET

Because it's not necessary, because it's done by the compiler. I already
mentioned that.

Hogwash. Not related at all.

Just quote what I wrote in context in future.

Man, and you are an MVP?

Wow, that's a perfect technical argument, isn't it?

What if I don't want to? But even then. Its besides the point.

It's the preferred way in VB. If you do not want to use VB, kindly use
another programming language.

But its ok for ASPX?

I already said that ASP.NET uses a different compilation/execution model
than project types which are compiled to a single binary.

Code Duplication? How about library references? How about the idea of
single sourcing?

I was referring to C/C++. This would have been clear if you would have
quoted me preserving the context.

You can have class files and a main

' file: class1.vb
class MyClass1
..
end class

' file: class2.vb
class MyClass2
..
end class

' file: main.vb
Module Module1
Sub Main()
End Sub
End Module

with no namespace requirements and compile it like

vbc main.vb class1.vb class2.vb

which is basically the same ideas of having:

#include "class1.vb"
#include "class2.vb"
Module Module1
Sub Main()
End Sub
End Module

Please, I think you mind is molded about GUI IDE development and now power
programming console development methods. Its a side note, but the IDE
does blind people of programming methods.

Most of the existing VB code is written in VS. Thus the language is
optimized for a modern IDE. Nevertheless, as your first above sample
demonstrated, it's even possible to get to the exact same result of what's
shown in your second sample in VB, even by manually compiling via the
command line compiler.

 

[Mike]

I don't see how your example would have any benefit above simply adding
some_common_stuff.vb and useful_classes.vb to the project.

A experience broad language developer will understand it better I
guess. But also:

1) The IDE is not the only way to do development. There are such
things as power programming editors, and console based code production
and building.

2) Its already done via assembly configuration or project files. So
its really not a foreign idea.

3) The IDE methods creates copies which can create version control
issues with multiple copies of the same source laying around.
You have to create a full project to link in the reference and if you
create alot of code like we do, then is highly unproductive.

What is it that
this would add as I'm not seeing any visibility change implied.

Perhaps a useful "include use case" is the following:

#include "StandardImports.inc"
public class Foo
end class

I find it hard to understand how any DEVELOPER does not see "general"
value, but that just might mean we have a different mindset in the VB
world - which is ok, but I was something you had to take account when
I work with engineers with VB only Application developers.

where StandardImports.inc lists the imports you want. I don't think this
ends up saving much typing however as I just use the refactor tools to add
the imports as I encounter the need for them.

Like I said, you don't understand if you never use it before. I can
imagine if i started with VB and never had the idea presented, then
its an foreign idea and maybe I too will begin to tell every
programmers its not a useful idea to have in VB - simply because what
you don't know doesn't apply very well.

Its really ashame that even as VB has evolved to VB.NET, that you
still see this closed minded one way only methods.

--

 

[Family Tree Mike]

Like I said, you don't understand if you never use it before. I can
imagine if i started with VB and never had the idea presented, then
its an foreign idea and maybe I too will begin to tell every
programmers its not a useful idea to have in VB - simply because what
you don't know doesn't apply very well.

Its really ashame that even as VB has evolved to VB.NET, that you
still see this closed minded one way only methods.

Of course it is not obvious from what I wrote, that I have experience with
include statements. Suffice to say, I do. I'm one of the few guys who can
read Fortran IV here.

You seem to be of the opinion that because you used it elsewhere, that it
should be useful here in VB.Net. I'm just saying that it is not readily
apparent what adding an include statement to the syntax set adds. I'm not
closed minded on the use of includes. You just have not stated your point of
view very well, yet.

Mike

 

[Mike]

Of course it is not obvious from what I wrote, that I have experience with
include statements. Suffice to say, I do. I'm one of the few guys who can
read Fortran IV here.

You can *include" me as well.

You seem to be of the opinion that because you used it elsewhere, that it
should be useful here in VB.Net. I'm just saying that it is not readily
apparent what adding an include statement to the syntax set adds.

For the same reason conditional compilation directives were added to
compile a block vs not to compile a block.

For the same reason you have IMPORTS to reference an compiled object.

I'm not closed minded on the use of includes. You just have not
stated your point of view very well, yet.

Fair enough.

First, single sourcing is very important concept. Currently under the
IDE, to ADD "Existing Item" it makes a copy. It would preferred to
have some method within the main project file to say

IMPORTS "FQDN source code" as oppose to assembly namespace

or just use well known traditional concept of #include, after all
VB.NET is really sprinkled with these related ideas.

I have thousands, millions of line of code under my belt. Sometimes I
will do:

#include "mylib.h"

to link in a "reference" (object) or maybe I might just do:

#include "mylib.cpp"

to burn it all in. The same idea can apply in VB.NET which is being
molded to be more attractive to people like myself by sprinkling it
with "common language" concepts.

Second, it is difficult to explain all the reason because they are
VAST, every programmer has their reasons. Like without out product
line source codes, look at other large projects where the source code
is LOADED with both imports and includes - because the language
allowed it.

#include "mylib.h" <-- akin to INTERFACE file
#include "mylib2.cpp" <-- akin to project File
#prama comment(lib,"mylib3.lib") <-- akin to IMPORTS

Thirds, I use alot of compiler #define statements or as it would be in
VB.NET, #const and including in on a single or more files, would be a
godsend.

Forth, personally, I program mostly via the console with my power
programming editor of nearly 30 years - qedit. I have tons of code
snippnets that I generally create and save include like a puzzle. I
don't need this to be .NET dlls in only to use it. I have created
some basic VB.NET classes and right now I needed to add it (the
include files) to the VBC options setup in my F9 compiler action. A
simple #include would be very useful here.

So maybe that doesn't explain it the "reasons" fully that is only
understood by those who are active with these concepts, but honestly,
that is really besides the point here. What is more disconcerting is
the attitude that this or that is not needed, useful. I *hate* people
say such things.

--

 

[Herfried K. Wagner [MVP]]

Just about every developer outside of VB world. Plus the designers of VB
themselves! <g>

Developers outside VB typically do not use VB, so why please them by
including features they like in their programming language but do not fit
into VB's paradigms/concept?

Besides I am very 100% confident if VB supported include concept, you
would used it too.

Well, there's no substantial demand for the feature among the user base of
VB. Consequently there must be either other ways to achieve the same thing
or there is no demand to achieve it at all.

You guys need to stop being anal about something you don't have and come
up with silly justifications why this world is BETTER because
of it!

Designing a programming language is more than randomly adding features to
it. It's about providing a consistent feature set. Text pasting via
'#include' would not fit into VB's compilation model very well.