Classes vs. Modules

[Scott M.]

Re: Classes vs. Modules

An application that starts from the command line with different potential
switches attached is the one I had in mind. Another could be applications
that start differently based on the user logged into the domain. Really,
any application that has multiple startup paths where those startup paths
are determined in a non-GUI way.


"Tom Leylan" <tleylan@nospam .netwrote in message
news:e4uIhvUTHH A.496@TK2MSFTNG P06.phx.gbl...

Scott: Rather than just say "can benefit greatly" try to list one item,
two or three if there are than many benefits. I personally know of no
benefit so if you posted one it would help me and I'm sure others. What
don't we understand about this?
>
>
"Scott M." <s-mar@nospam.nosp amwrote in message
news:O79iODUTHH A.1636@TK2MSFTN GP02.phx.gbl...

>But don't forget that not all apps are Windows Forms apps. Console apps
>can benefit greatly from sub main.
>>
>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:UaqdnU71u 9Zty1DYnZ2dnUVZ WhednZ2d@comcas t.com...

>>On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:
>>>But if you were to create a class that handled program flow during
>>>startup,
>>>you'd be doing extra work to get you to exactly what you could have
>>>automaticall y with a module and Sub Main.
>>>>
>>>>
>>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>>news:9PqdnSI fra5JplDYnZ2dnU VZ_uHinZ2d@comc ast.com...
>>>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>>>I don't know if I agree with that. A module can be used as a
>>>>>starting
>>>>>point
>>>>>for your application along with a Sub Main. This can be helpful in
>>>>>directin g the flow of the application startup.
>>>>>
>>>>So can a class.
>>>>>
>>>>--
>>>>Tom Shelton
>>>
>>It's not any extra work to make a class the startup object versus a
>>module -
>>well except for maybe making a private sub new so that no one can make
>>instances of your Program class.
>>>
>>Of course, in VB 2005 - you pretty much have to use a form as your
>>startup
>>object anyway. You dont' get to do a submain. Well, that isn't
>>strictly
>>true, but if you want to use the application framework that VB.NET
>>provides
>>then you do (and why wouldn't you - visual styles, single instance app,
>>settings, etc).
>>>
>>--
>>Tom Shelton

>>
>>

>
>

[Scott M.]

Re: Classes vs. Modules

Hmmm, why don't I see Robin's message in this thread?


"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
news:VPOdnfPnqu mNpVPYnZ2dnUVZ_ tunnZ2d@comcast .com...

I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
conclusion that our neophyte troll doesn't know how to program. If he
can't drag it and drop it, he's lost. Now, he COULD prove me wrong, but I
doubt that he'll even attempt to. :)
>
Bruce
>
"RobinS" <RobinS@NoSpam. yah.nonewrote in message
news:xsidnT6DOo x6ilPYnZ2dnUVZ_ vyunZ2d@comcast .com...

>Why don't you post some code samples that show the same thing running in
>VB6 and VB2005 and show the performance statistics?
>>
>Robin S.
>Ts'i mahnu uterna ot twan ot geifur hingts uto.
>-----------------------------------------------

>
>

[Scott M.]

Re: Classes vs. Modules

Does that imply VB6 didn't use classes?

Sure! VB 6.0 was Object-Based, but not fully Object Oriented. It had
classes and almost all OO functionality minus the all-important inheritance.

>I thought it was based on a
prior version of the .NET run-time, and that that was still class
based.

Not at all! Before VB .NET 2003, there was VB 6.0 wich used a much simpler
runtime (MSVBVM60.dll - 1.5 MB). There was no .NET then.

>
Zytan
>

[Bruce W. Darby]

Re: Classes vs. Modules

Not sure Scott. Are you seeing other posts by Robin? Or did you
inadvertently add him to your killfile?

"Scott M." <s-mar@nospam.nosp amwrote in message
news:OewPq6WTHH A.1364@TK2MSFTN GP06.phx.gbl...

Hmmm, why don't I see Robin's message in this thread?
>
>
"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
news:VPOdnfPnqu mNpVPYnZ2dnUVZ_ tunnZ2d@comcast .com...

>I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
>conclusion that our neophyte troll doesn't know how to program. If he
>can't drag it and drop it, he's lost. Now, he COULD prove me wrong, but I
>doubt that he'll even attempt to. :)
>>
>Bruce
>>
>"RobinS" <RobinS@NoSpam. yah.nonewrote in message
>news:xsidnT6DO ox6ilPYnZ2dnUVZ _vyunZ2d@comcas t.com...

>>Why don't you post some code samples that show the same thing running in
>>VB6 and VB2005 and show the performance statistics?
>>>
>>Robin S.
>>Ts'i mahnu uterna ot twan ot geifur hingts uto.
>>-----------------------------------------------

>>
>>

>
>

[Tom Leylan]

Re: Classes vs. Modules

In other threads (and these were recent) I wrote much the same thing. I
specifically mentioned that people who use modules and/or functions like
UCASE() would be unlikely to change due to anything I wrote. I specifically
mentioned that if I was trying to influence anybody, it would be the people
who have yet to adopt a methodology. And I generally suggest they do more
than read a VB newsgroup in order to make an informed decision.

All I am asking from you is when you write "in certain situations" that you
define one of them so people reading this (and these message exist forever)
will understand when they should choose a module over a class.

If the extra work you mentioned takes a week I'll concede the point, if the
extra work is one minute I'd say the word "extra" is a bit of a stretch.


"Scott M." <s-mar@nospam.nosp amwrote in message
news:%23hDHk3WT HHA.3996@TK2MSF TNGP04.phx.gbl. ..

Tom, I think this really comes down to "you say tomatoe and I say tomato".
I have had this conversation many times albeit about other aspects of VB
vs. the Framework. Should VB language functions be used over .NET
Framework classes and methods, for example? The debate rages on.
>
What I do think is that no one can say with certainty "do" or "do not" use
modules. They exist and by that very fact, they are viable. I never
indicated that they "should" be used, nor did I even indicate that they
should "always" be used. In fact, I rarely use them. But in certain
situations, they serve a purpose and can be of help.
>
If you really want to have an objective conversation here, you must be
willing to concede that your comments about VB legacies are your opinions
and not facts. I happen to largely agree with you personally, but that
doesn't change the fact that it's just my preference/opinion, it doesn't
make it gospel.
>
>
>
>
"Tom Leylan" <tleylan@nospam .netwrote in message
news:%23%23JN1B UTHHA.1552@TK2M SFTNGP05.phx.gb l...

>I'll bet the transition from the "here is what I like" type of discussion
>to one based upon actual issues will be difficult but let's try :-)
>>
>Scott wrote"you'd be doing extra work..." so the next logical question
>is, what extra work? I've always used an application class to start the
>apps so how much extra work have I been creating for myself? Then Tom S.
>suggests that VB 2005 apps probably start with forms.
>>
>What I'm asking each person to consider is... perhaps the type of apps
>you write are different (maybe the most common) but still not the only
>type. There are business app, there are utilities, there are "kiosks" and
>there are services. Some have no front-end, some minimal and some only
>need console-based front-ends. Some (think ATM machine) typically have
>no menu, and few, if any pop-up forms. Some apps are used in-house only,
>some are intended for distribution and of those some to closely
>controlled clients and some sold as products to the general public.
>>
>From another direction, some (and I suspect many here) are single-person
>projects but that isn't too common in the business software world.
>Team-based development isn't filled with "here is what I like" type
>decisions or when they are the resulting app is a mess. A project
>estimated to take 10 developers one year to complete isn't impacted by
>the "extra work" if that means 1 minute to create a Sub Main in a class.
>>
>Programmers in typical business settings aren't (necessarily) VB experts
>and it is my preference (even when the project is being written in VB)
>that they are not . This has nothing to do with VB but rather a lot to
>do with any self-professed language "expert." Recall the quote: "To the
>man with a hammer everything looks like a nail." We've all met Access,
>FoxPro, VB, Java and other language developers explaining how they could
>have written the same app in half an hour and there would be no bugs. It
>isn't true, it did have bugs and the apps often looked crude. They often
>don't aid the user in doing their job but rather restrict the user making
>it harder for them to do their job.
>>
>My point is that a style of development, the adoption of some rule, the
>choice of using modules, the use of public variables, the calling of
>framework methods rather than relying on VB functions, etc. is impacted
>by all of the above. If a company somewhere is having a hard time
>transitionin g a VB6 app to .Net (assuming that is a goal) it can be in
>large part because they wrote a "VB6 app" rather than an application
>using VB6. Using every VB6 trick in the book can lock them into a system
>that is hard to transition when no other language has whatever VB6-isms
>they are using. I'm not suggesting this is a VB-only problem, the tighter
>the connection to any single language the harder it will be to migrate
>and business needs may dictate a migration.
>>
>So when people write "here is what I do" it might help if the person
>considering it ask themself, is my situation similar? Am I writing a
>similar type app, under similar conditions and intended for a similar
>audience? Just because somebody writes "that's what they do at Citibank"
>doesn't it make it right for you, unless perhaps you too are a large
>bank. What works for your home-use contact manager program isn't likely
>to work for the FDIC or NASA or on the floor of the NYSE.
>>
>Anyway that's my 2 cents (or was that 5 cents?)
>>
>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:UaqdnU71u 9Zty1DYnZ2dnUVZ WhednZ2d@comcas t.com...

>>On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:
>>>But if you were to create a class that handled program flow during
>>>startup,
>>>you'd be doing extra work to get you to exactly what you could have
>>>automaticall y with a module and Sub Main.
>>>>
>>>>
>>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>>news:9PqdnSI fra5JplDYnZ2dnU VZ_uHinZ2d@comc ast.com...
>>>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>>>I don't know if I agree with that. A module can be used as a
>>>>>starting
>>>>>point
>>>>>for your application along with a Sub Main. This can be helpful in
>>>>>directin g the flow of the application startup.
>>>>>
>>>>So can a class.
>>>>>
>>>>--
>>>>Tom Shelton
>>>
>>It's not any extra work to make a class the startup object versus a
>>module -
>>well except for maybe making a private sub new so that no one can make
>>instances of your Program class.
>>>
>>Of course, in VB 2005 - you pretty much have to use a form as your
>>startup
>>object anyway. You dont' get to do a submain. Well, that isn't
>>strictly
>>true, but if you want to use the application framework that VB.NET
>>provides
>>then you do (and why wouldn't you - visual styles, single instance app,
>>settings, etc).
>>>
>>--
>>Tom Shelton

>>
>>

>
>

[Tom Leylan]

Re: Classes vs. Modules

Scott: I just don't know where you are coming from on this. Have you tried
placing Sub Main in a class and your command line switches didn't work or
are you imagining it could be problematic and avoiding it as such?

I will guarantee you that my standard app framework supports both GUI and
console apps and that both start with exactly the same class and the same
Sub Main. I simply change the build setting on the compiler. And of course
I can easily read the command line switches and "start differently" based
upon the user. Seriously if I couldn't handle such trivial things using my
app class I would have used a module yet I haven't.

Check with Cor and others and they will explain that a module is in fact a
predefined class in VB.Net.


"Scott M." <s-mar@nospam.nosp amwrote in message
news:ugxhc5WTHH A.4260@TK2MSFTN GP06.phx.gbl...

An application that starts from the command line with different potential
switches attached is the one I had in mind. Another could be applications
that start differently based on the user logged into the domain. Really,
any application that has multiple startup paths where those startup paths
are determined in a non-GUI way.
>
>
"Tom Leylan" <tleylan@nospam .netwrote in message
news:e4uIhvUTHH A.496@TK2MSFTNG P06.phx.gbl...

>Scott: Rather than just say "can benefit greatly" try to list one item,
>two or three if there are than many benefits. I personally know of no
>benefit so if you posted one it would help me and I'm sure others. What
>don't we understand about this?
>>
>>
>"Scott M." <s-mar@nospam.nosp amwrote in message
>news:O79iODUTH HA.1636@TK2MSFT NGP02.phx.gbl.. .

>>But don't forget that not all apps are Windows Forms apps. Console apps
>>can benefit greatly from sub main.
>>>
>>>
>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>news:UaqdnU71 u9Zty1DYnZ2dnUV ZWhednZ2d@comca st.com...
>>>On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:
>>>>But if you were to create a class that handled program flow during
>>>>startup,
>>>>you'd be doing extra work to get you to exactly what you could have
>>>>automatical ly with a module and Sub Main.
>>>>>
>>>>>
>>>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>>>news:9PqdnS Ifra5JplDYnZ2dn UVZ_uHinZ2d@com cast.com...
>>>>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>>>>I don't know if I agree with that. A module can be used as a
>>>>>>startin g
>>>>>>point
>>>>>>for your application along with a Sub Main. This can be helpful in
>>>>>>directi ng the flow of the application startup.
>>>>>>
>>>>>So can a class.
>>>>>>
>>>>>--
>>>>>Tom Shelton
>>>>
>>>It's not any extra work to make a class the startup object versus a
>>>module -
>>>well except for maybe making a private sub new so that no one can make
>>>instances of your Program class.
>>>>
>>>Of course, in VB 2005 - you pretty much have to use a form as your
>>>startup
>>>object anyway. You dont' get to do a submain. Well, that isn't
>>>strictly
>>>true, but if you want to use the application framework that VB.NET
>>>provides
>>>then you do (and why wouldn't you - visual styles, single instance app,
>>>settings, etc).
>>>>
>>>--
>>>Tom Shelton
>>>
>>>

>>
>>

>
>

[RobinS]

Re: Classes vs. Modules


"Zytan" <zytanlithium@y ahoo.comwrote in message
news:1171140568 .405088.88860@a 75g2000cwd.goog legroups.com...

>Again, why don't you create a small project in VB6 and in VB2005 and
>show
>the performance statistics?

>
Does that imply VB6 didn't use classes? I thought it was based on a
prior version of the .NET run-time, and that that was still class
based.
>
Zytan
>

VB6 was pre-.Net. Technically, it had classes, but not true OO
capabilities.

Robin S.

[Cor Ligthert [MVP]]

Re: Classes vs. Modules


My point is that a class (in Dutch the word is almost the same and has the
same meaning as in English) tells someting about a type. A shared class
tells nothing, it is a stand alone object not something that describes a
group.

A module is a much beter name for me for that.

For me it is more that it is not the right word in C languages as well. I
would propose to call it there as well modules.

Cor

"Tom Leylan" <tleylan@nospam .netschreef in bericht
news:uKYR6ZWTHH A.5100@TK2MSFTN GP06.phx.gbl...

We've been over this before on other threads. The module you think you
wrote has been determined to be a class (if you believe what others posted
here about modules) so you haven't constructed a module but rather a class
with a VB-only name attached to it. What is the point of that? And you
don't have to answer I can almost list the names of the people who like
modules and those who don't see a need from the other threads.
>
Do like the BASIC variable naming convention that string variables must
end with a $ symbol? Would it be a fair guess that neither you nor
Herfried mind that that convention was dropped? So is this a matter of
figuring out which conventions you guys will let drop from the language.
:-)
>
Can you subclass your module? Is it serializable?
>
>
"Cor Ligthert [MVP]" <notmyfirstname @planet.nlwrote in message
news:%23UXHK3UT HHA.3980@TK2MSF TNGP02.phx.gbl. ..

>Tom,
>>
>I still don't understand your preference, see this shared class and the
>module.
>>
>Public Class TheClass
> Private Shared mymember As Integer
> Friend Shared Property Member() As Integer
> Get
> Return mymember
> End Get
> Set(ByVal value As Integer)
> mymember = value
> End Set
> End Property
> Public Shared Sub Method()
> End Sub
>End Class
>>
>Public Module TheModule
> Private mymember As Integer
> Friend Property Member() As Integer
> Get
> Return mymember
> End Get
> Set(ByVal value As Integer)
> mymember = value
> End Set
> End Property
> Public Sub Method()
> End Sub
>End Module
>>
>I find the module much nicer. (For those who saw my name in this thread,
>I have changed my idea about this in favour for a *good* written module.
>That good is very important in that)
>>
>Cor
>>
>"Tom Leylan" <tleylan@nospam .netschreef in bericht
>news:ezX1wdKTH HA.4956@TK2MSFT NGP04.phx.gbl.. .

>>Just stick with your original concerns and forget about modules. Yes of
>>course one can use a module, one can place their Sub Main in a module
>>and they can put commonly used functions and procedures in a module
>>however it isn't necessary and lots of people (including me) don't.
>>>
>>I too have a Sub Main but mine just happens to be a Shared method of my
>>standard application class. This application class can contain any
>>routines common to the app as well so one continues to reap all the
>>benefits of a class implementation with no downside. Additionally
>>should it ever be needed I can convert (or pay somebody to convert) the
>>entire app to C# or even Java because there is nothing "VB-only" about
>>the application. The class, method, property modelling will translate
>>across the board.
>>>
>>I'll suggest you keep your options open.
>>>
>>"Zytan" <zytanlithium@y ahoo.comwrote in message
>>news:11710595 55.318195.20081 0@k78g2000cwa.g ooglegroups.com ...
>>>>Personall y, I do /not/ use modules to store variables and program
>>>>state. I
>>>>use modules only in very few cases: The project's main entry point is
>>>>placed in a module 'Program'. In addition, common functions are
>>>>placed in
>>>>modules if their use makes sense throughout the project, similar to
>>>>"Microsoft. VisualBasic.dll " and its modules. In this case modules are
>>>>used
>>>>to structure a huge set of functions, but make them easily accessible
>>>>in
>>>>IntelliSens e everywhere.
>>>>
>>>Understood . Thanks. I guess I'm paranoid about having things
>>>floating around, so I want them under something, say Math.Pi instead
>>>of just Pi.
>>>>
>>>Zytan.
>>>>
>>>
>>>

>>
>>

>
>

[Cor Ligthert [MVP]]

Re: Classes vs. Modules

Scott,

Never thought about that Tomatoes and tomato. I say always colour and you
say color.
But a good sample.

Cor

"Scott M." <s-mar@nospam.nosp amschreef in bericht
news:%23hDHk3WT HHA.3996@TK2MSF TNGP04.phx.gbl. ..

Tom, I think this really comes down to "you say tomatoe and I say tomato".
I have had this conversation many times albeit about other aspects of VB
vs. the Framework. Should VB language functions be used over .NET
Framework classes and methods, for example? The debate rages on.
>
What I do think is that no one can say with certainty "do" or "do not" use
modules. They exist and by that very fact, they are viable. I never
indicated that they "should" be used, nor did I even indicate that they
should "always" be used. In fact, I rarely use them. But in certain
situations, they serve a purpose and can be of help.
>
If you really want to have an objective conversation here, you must be
willing to concede that your comments about VB legacies are your opinions
and not facts. I happen to largely agree with you personally, but that
doesn't change the fact that it's just my preference/opinion, it doesn't
make it gospel.
>
>
>
>
"Tom Leylan" <tleylan@nospam .netwrote in message
news:%23%23JN1B UTHHA.1552@TK2M SFTNGP05.phx.gb l...

>I'll bet the transition from the "here is what I like" type of discussion
>to one based upon actual issues will be difficult but let's try :-)
>>
>Scott wrote"you'd be doing extra work..." so the next logical question
>is, what extra work? I've always used an application class to start the
>apps so how much extra work have I been creating for myself? Then Tom S.
>suggests that VB 2005 apps probably start with forms.
>>
>What I'm asking each person to consider is... perhaps the type of apps
>you write are different (maybe the most common) but still not the only
>type. There are business app, there are utilities, there are "kiosks" and
>there are services. Some have no front-end, some minimal and some only
>need console-based front-ends. Some (think ATM machine) typically have
>no menu, and few, if any pop-up forms. Some apps are used in-house only,
>some are intended for distribution and of those some to closely
>controlled clients and some sold as products to the general public.
>>
>From another direction, some (and I suspect many here) are single-person
>projects but that isn't too common in the business software world.
>Team-based development isn't filled with "here is what I like" type
>decisions or when they are the resulting app is a mess. A project
>estimated to take 10 developers one year to complete isn't impacted by
>the "extra work" if that means 1 minute to create a Sub Main in a class.
>>
>Programmers in typical business settings aren't (necessarily) VB experts
>and it is my preference (even when the project is being written in VB)
>that they are not . This has nothing to do with VB but rather a lot to
>do with any self-professed language "expert." Recall the quote: "To the
>man with a hammer everything looks like a nail." We've all met Access,
>FoxPro, VB, Java and other language developers explaining how they could
>have written the same app in half an hour and there would be no bugs. It
>isn't true, it did have bugs and the apps often looked crude. They often
>don't aid the user in doing their job but rather restrict the user making
>it harder for them to do their job.
>>
>My point is that a style of development, the adoption of some rule, the
>choice of using modules, the use of public variables, the calling of
>framework methods rather than relying on VB functions, etc. is impacted
>by all of the above. If a company somewhere is having a hard time
>transitionin g a VB6 app to .Net (assuming that is a goal) it can be in
>large part because they wrote a "VB6 app" rather than an application
>using VB6. Using every VB6 trick in the book can lock them into a system
>that is hard to transition when no other language has whatever VB6-isms
>they are using. I'm not suggesting this is a VB-only problem, the tighter
>the connection to any single language the harder it will be to migrate
>and business needs may dictate a migration.
>>
>So when people write "here is what I do" it might help if the person
>considering it ask themself, is my situation similar? Am I writing a
>similar type app, under similar conditions and intended for a similar
>audience? Just because somebody writes "that's what they do at Citibank"
>doesn't it make it right for you, unless perhaps you too are a large
>bank. What works for your home-use contact manager program isn't likely
>to work for the FDIC or NASA or on the floor of the NYSE.
>>
>Anyway that's my 2 cents (or was that 5 cents?)
>>
>>
>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>news:UaqdnU71u 9Zty1DYnZ2dnUVZ WhednZ2d@comcas t.com...

>>On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:
>>>But if you were to create a class that handled program flow during
>>>startup,
>>>you'd be doing extra work to get you to exactly what you could have
>>>automaticall y with a module and Sub Main.
>>>>
>>>>
>>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>>news:9PqdnSI fra5JplDYnZ2dnU VZ_uHinZ2d@comc ast.com...
>>>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>>>I don't know if I agree with that. A module can be used as a
>>>>>starting
>>>>>point
>>>>>for your application along with a Sub Main. This can be helpful in
>>>>>directin g the flow of the application startup.
>>>>>
>>>>So can a class.
>>>>>
>>>>--
>>>>Tom Shelton
>>>
>>It's not any extra work to make a class the startup object versus a
>>module -
>>well except for maybe making a private sub new so that no one can make
>>instances of your Program class.
>>>
>>Of course, in VB 2005 - you pretty much have to use a form as your
>>startup
>>object anyway. You dont' get to do a submain. Well, that isn't
>>strictly
>>true, but if you want to use the application framework that VB.NET
>>provides
>>then you do (and why wouldn't you - visual styles, single instance app,
>>settings, etc).
>>>
>>--
>>Tom Shelton

>>
>>

>
>

[Herfried K. Wagner [MVP]]

Re: Classes vs. Modules

Tom,

"Tom Leylan" <tleylan@nospam .netschrieb:

We've been over this before on other threads. The module you think you
wrote has been determined to be a class (if you believe what others posted
here about modules) so you haven't constructed a module but rather a class
with a VB-only name attached to it.

In the current implementation of .NET which VB is based on, it's based on
classes under the hoods. However, the concept of modules in VB exists
already longer than .NET exists and modules are clearly not the same as
classes are.

Semantically modules and classes are entirely different. Modules are a
loose grouping construct whereas classes represent instantiable entities
(there are a few exceptions where classes cannot be instantiated, but often
the reason for that is that their instances would not form a complete
entity. That's why I think that modules are an important feature. They
simply cannot be mimicked using a class (in VB/C# semantics, not IL
semantics) because classes are classes and modules are modules.

Do like the BASIC variable naming convention that string variables must
end with a $ symbol? Would it be a fair guess that neither you nor
Herfried mind that that convention was dropped?

In this particular case I don't see any reason for dropping the convention.
However, I'd prefer if the IDE turned 'Dim i%' into 'Dim i As Integer'
automatically.

Can you subclass your module? Is it serializable?

As modules do not form what I call entities, I don't see a reason for
subclassing and serialization. Namespaces cannot be serialized too,
although they are a language construct. Modules and classes have (from a VB
point of view) different semantics and thus different characteristics
(operations that can be performed, ways to make use of them, ...).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

Re: Classes vs. Modules

Cor,

"Cor Ligthert [MVP]" <notmyfirstname @planet.nlschri eb:

My point is that a class (in Dutch the word is almost the same and has the
same meaning as in English) tells someting about a type. A shared class
tells nothing, it is a stand alone object not something that describes a
group.
>
A module is a much beter name for me for that.

I agree. Overloading the meaning of 'Class' for different things is hardly
a good idea.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Scott M.]

Re: Classes vs. Modules

All I am asking from you is when you write "in certain situations" that

you define one of them so people reading this (and these message exist
forever) will understand when they should choose a module over a class.

I've already responded to your request, but my first response (in certain
situations) is perfectly valid. It just seems that you are up on a soapbox
here.

If the extra work you mentioned takes a week I'll concede the point, if
the extra work is one minute I'd say the word "extra" is a bit of a
stretch.

That's your "opinion" and you are entitled to it. If I can find something
that saves me a minute every so often and it does just what I need it to,
I'll take the extra minute.

>
>
"Scott M." <s-mar@nospam.nosp amwrote in message
news:%23hDHk3WT HHA.3996@TK2MSF TNGP04.phx.gbl. ..

>Tom, I think this really comes down to "you say tomatoe and I say
>tomato". I have had this conversation many times albeit about other
>aspects of VB vs. the Framework. Should VB language functions be used
>over .NET Framework classes and methods, for example? The debate rages
>on.
>>
>What I do think is that no one can say with certainty "do" or "do not"
>use modules. They exist and by that very fact, they are viable. I never
>indicated that they "should" be used, nor did I even indicate that they
>should "always" be used. In fact, I rarely use them. But in certain
>situations, they serve a purpose and can be of help.
>>
>If you really want to have an objective conversation here, you must be
>willing to concede that your comments about VB legacies are your opinions
>and not facts. I happen to largely agree with you personally, but that
>doesn't change the fact that it's just my preference/opinion, it doesn't
>make it gospel.
>>
>>
>>
>>
>"Tom Leylan" <tleylan@nospam .netwrote in message
>news:%23%23JN1 BUTHHA.1552@TK2 MSFTNGP05.phx.g bl...

>>I'll bet the transition from the "here is what I like" type of
>>discussion to one based upon actual issues will be difficult but let's
>>try :-)
>>>
>>Scott wrote"you'd be doing extra work..." so the next logical question
>>is, what extra work? I've always used an application class to start the
>>apps so how much extra work have I been creating for myself? Then Tom
>>S. suggests that VB 2005 apps probably start with forms.
>>>
>>What I'm asking each person to consider is... perhaps the type of apps
>>you write are different (maybe the most common) but still not the only
>>type. There are business app, there are utilities, there are "kiosks"
>>and there are services. Some have no front-end, some minimal and some
>>only need console-based front-ends. Some (think ATM machine) typically
>>have no menu, and few, if any pop-up forms. Some apps are used in-house
>>only, some are intended for distribution and of those some to closely
>>controlled clients and some sold as products to the general public.
>>>
>>From another direction, some (and I suspect many here) are single-person
>>projects but that isn't too common in the business software world.
>>Team-based development isn't filled with "here is what I like" type
>>decisions or when they are the resulting app is a mess. A project
>>estimated to take 10 developers one year to complete isn't impacted by
>>the "extra work" if that means 1 minute to create a Sub Main in a class.
>>>
>>Programmers in typical business settings aren't (necessarily) VB experts
>>and it is my preference (even when the project is being written in VB)
>>that they are not . This has nothing to do with VB but rather a lot to
>>do with any self-professed language "expert." Recall the quote: "To the
>>man with a hammer everything looks like a nail." We've all met Access,
>>FoxPro, VB, Java and other language developers explaining how they could
>>have written the same app in half an hour and there would be no bugs.
>>It isn't true, it did have bugs and the apps often looked crude. They
>>often don't aid the user in doing their job but rather restrict the user
>>making it harder for them to do their job.
>>>
>>My point is that a style of development, the adoption of some rule, the
>>choice of using modules, the use of public variables, the calling of
>>framework methods rather than relying on VB functions, etc. is impacted
>>by all of the above. If a company somewhere is having a hard time
>>transitioni ng a VB6 app to .Net (assuming that is a goal) it can be in
>>large part because they wrote a "VB6 app" rather than an application
>>using VB6. Using every VB6 trick in the book can lock them into a system
>>that is hard to transition when no other language has whatever VB6-isms
>>they are using. I'm not suggesting this is a VB-only problem, the
>>tighter the connection to any single language the harder it will be to
>>migrate and business needs may dictate a migration.
>>>
>>So when people write "here is what I do" it might help if the person
>>considering it ask themself, is my situation similar? Am I writing a
>>similar type app, under similar conditions and intended for a similar
>>audience? Just because somebody writes "that's what they do at
>>Citibank" doesn't it make it right for you, unless perhaps you too are a
>>large bank. What works for your home-use contact manager program isn't
>>likely to work for the FDIC or NASA or on the floor of the NYSE.
>>>
>>Anyway that's my 2 cents (or was that 5 cents?)
>>>
>>>
>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>news:UaqdnU71 u9Zty1DYnZ2dnUV ZWhednZ2d@comca st.com...
>>>On 2007-02-10, Scott M. <s-mar@nospam.nosp amwrote:
>>>>But if you were to create a class that handled program flow during
>>>>startup,
>>>>you'd be doing extra work to get you to exactly what you could have
>>>>automatical ly with a module and Sub Main.
>>>>>
>>>>>
>>>>"Tom Shelton" <tom_shelton@co mcastXXXXXXX.ne twrote in message
>>>>news:9PqdnS Ifra5JplDYnZ2dn UVZ_uHinZ2d@com cast.com...
>>>>>On 2007-02-09, Scott M. <s-mar@nospam.nosp amwrote:
>>>>>>I don't know if I agree with that. A module can be used as a
>>>>>>startin g
>>>>>>point
>>>>>>for your application along with a Sub Main. This can be helpful in
>>>>>>directi ng the flow of the application startup.
>>>>>>
>>>>>So can a class.
>>>>>>
>>>>>--
>>>>>Tom Shelton
>>>>
>>>It's not any extra work to make a class the startup object versus a
>>>module -
>>>well except for maybe making a private sub new so that no one can make
>>>instances of your Program class.
>>>>
>>>Of course, in VB 2005 - you pretty much have to use a form as your
>>>startup
>>>object anyway. You dont' get to do a submain. Well, that isn't
>>>strictly
>>>true, but if you want to use the application framework that VB.NET
>>>provides
>>>then you do (and why wouldn't you - visual styles, single instance app,
>>>settings, etc).
>>>>
>>>--
>>>Tom Shelton
>>>
>>>

>>
>>

>
>

[Scott M.]

Re: Classes vs. Modules


"Tom Leylan" <tleylan@nospam .netwrote in message
news:u3wp%23PXT HHA.496@TK2MSFT NGP06.phx.gbl.. .

Scott: I just don't know where you are coming from on this. Have you
tried placing Sub Main in a class and your command line switches didn't
work or are you imagining it could be problematic and avoiding it as such?

I'm so sorry that you are having such a hard time Tom. To answer your
question, no I haven't. But, that what not the OP. Modules are *another*
way of handling such things. I find them easier for these situations than
custom classes. I find them quicker to set up and use than custom classes
and I find them to make more sense from a *flow* standpoint in these
situations.

No one said that classes wouldnt do (and that seems to be your stance here).

I will guarantee you that my standard app framework supports both GUI and
console apps and that both start with exactly the same class and the same
Sub Main. I simply change the build setting on the compiler. And of
course I can easily read the command line switches and "start differently"
based upon the user. Seriously if I couldn't handle such trivial things
using my app class I would have used a module yet I haven't.

See my comments above.

Check with Cor and others and they will explain that a module is in fact a
predefined class in VB.Net.

Thanks but I don't need the homework assignment. I know exactly what a
module is and all I've said here is that in some situations they are easier
to use. You seem very threatened by this statement.

[Scott M.]

Re: Classes vs. Modules

Must have. I don't see anything from Robin in this entire thread.


"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
news:e8GdnRTsgZ Vgw1PYnZ2dnUVZ_ sWdnZ2d@comcast .com...

Not sure Scott. Are you seeing other posts by Robin? Or did you
inadvertently add him to your killfile?
>
"Scott M." <s-mar@nospam.nosp amwrote in message
news:OewPq6WTHH A.1364@TK2MSFTN GP06.phx.gbl...

>Hmmm, why don't I see Robin's message in this thread?
>>
>>
>"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
>news:VPOdnfPnq umNpVPYnZ2dnUVZ _tunnZ2d@comcas t.com...

>>I'll answer that for him, Robin.... because he CAN'T!! I'm coming to the
>>conclusion that our neophyte troll doesn't know how to program. If he
>>can't drag it and drop it, he's lost. Now, he COULD prove me wrong, but
>>I doubt that he'll even attempt to. :)
>>>
>>Bruce
>>>
>>"RobinS" <RobinS@NoSpam. yah.nonewrote in message
>>news:xsidnT6D Oox6ilPYnZ2dnUV Z_vyunZ2d@comca st.com...
>>>Why don't you post some code samples that show the same thing running
>>>in VB6 and VB2005 and show the performance statistics?
>>>>
>>>Robin S.
>>>Ts'i mahnu uterna ot twan ot geifur hingts uto.
>>>-----------------------------------------------
>>>
>>>

>>
>>

>
>

[RobinS]

Re: Classes vs. Modules

There's only been one post by me (Robin) *in* this entire thread. Do you
see this one?

Robin S.
----------------------
"Scott M." <s-mar@nospam.nosp amwrote in message
news:OAHhyFZTHH A.4076@TK2MSFTN GP05.phx.gbl...

Must have. I don't see anything from Robin in this entire thread.
>
>
"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
news:e8GdnRTsgZ Vgw1PYnZ2dnUVZ_ sWdnZ2d@comcast .com...

>Not sure Scott. Are you seeing other posts by Robin? Or did you
>inadvertentl y add him to your killfile?
>>
>"Scott M." <s-mar@nospam.nosp amwrote in message
>news:OewPq6WTH HA.1364@TK2MSFT NGP06.phx.gbl.. .

>>Hmmm, why don't I see Robin's message in this thread?
>>>
>>>
>>"Bruce W. Darby" <kracorat@atcom cast.netwrote in message
>>news:VPOdnfPn qumNpVPYnZ2dnUV Z_tunnZ2d@comca st.com...
>>>I'll answer that for him, Robin.... because he CAN'T!! I'm coming to
>>>the conclusion that our neophyte troll doesn't know how to program. If
>>>he can't drag it and drop it, he's lost. Now, he COULD prove me wrong,
>>>but I doubt that he'll even attempt to. :)
>>>>
>>>Bruce
>>>>
>>>"RobinS" <RobinS@NoSpam. yah.nonewrote in message
>>>news:xsidnT6 DOox6ilPYnZ2dnU VZ_vyunZ2d@comc ast.com...
>>>>Why don't you post some code samples that show the same thing running
>>>>in VB6 and VB2005 and show the performance statistics?
>>>>>
>>>>Robin S.
>>>>Ts'i mahnu uterna ot twan ot geifur hingts uto.
>>>>-----------------------------------------------
>>>>
>>>>
>>>
>>>

>>
>>

>
>