namespace v. module, events v. calling subs?

[JoeBobBriggs]

Hi,

I'm new to VB, and to VB.NET in particular. My background in VC++ 6.0 is fairly extensive, but several topics just weren't needed on the jobs that I've held and I haven't learned about them too much, so please forgive my ignorance. I've made a list (checkin' it twice) of areas where I'd like to flesh things out a bit more, and .NET and VB are on that list.

I'm a little confused on the differences between a module (module statement) and namespaces. It used to be that a 'module' was loosely defined. Namespaces seem to be just a method of defining a code block, for scope and/or resolving name clashes and what not. Then what is a module for? Are there nesting rules such as "Modules can contain several namespaces but namespaces cannot contain several modules" or anything like that? An overview of these two paradigms, e.g. contrast and compare, would be very helpful ...thanks in advance!

Secondly, events are not something that I've dealt with much in the past ...same with Interfaces. It seems to me that an exposed interface isn't much different than an exposed public function (etc) in a class definition. Both facilitate encapsulation, so what gives? And how is raising an event in your code any different from just calling the procedure or function that the raised event would call anyway?

Signed,
Cornfused (that's me, Brian)

 

[vis781]

Its a bit late here so i'll try to tackle the first couple for you...

Modules in vb.net are just another kind of class. When you add a module to an application, in the background, vb.net adds a class wrapper around it anyway. In addition it is complied with a private constructor and all of it's methods and fields are set to shared. Modules ARE a part of object oriented prgramming in vb.net. So what is a module? it is simply a way to access methods and fields without having to go through instantiating a class. Modules are not just there for backwards compatibiltity reasons they are there to group and organise methods that are more utility methods than part of a class.


Ok next bit....

Interfaces.

This is the .Net way of implemeting polymorphism. Interfaces, i thank techgnome for this example, are a 'set contract between classes'. Through interfaces we can specify methods that a component MUST implement without actually having to specify how it is implemeted.Once an interface has been implemented all the methods of that interface must be implemented. With interfaces you get a way to use muiltiple inheritance. It gives us advantages like strong typing and early binding.

 

[TechGnome]

Here's that trhead vis was just talking about:
http://www.vbdotnetforums.com/showthread.php?t=6780

-tg

 

[JohnH]

Events is about what happens when some condition occur. You can for instance create a class and add an event to tell when it has finished doing different stages of work.

Several different applications can use this class as an object in different ways. They all do different stuff when your class has done that job for them, but you don't know (or would want to care) what they all want to do, and you can of course not write every application in the whole world that could possibly have a use for this and include it in your class... So you simply add events to tell what happens and raise them when it happens, and let anyone using that class do what they want. They know when to do it because you tell them through the events.

As .Net is Object Oriented and Event Driven, the events is the glue that binds the objects together, is it not?
(Try thinking about all the objects as static billiard balls. Player starts by hitting the white one, very accurately, to play the others in a specific pattern into the board holes. Player can utilize both other balls and walls to achieve different motion. Every interaction between any object is an event. Every event changes the properties of the objects involved, like direction and velocity etc.)

http://en.wikipedia.org/wiki/Object-oriented_programming