[quoted text, click to view]

Object oriented languages have long (dare I say always?) supported the
concept of "class methods" and "instance methods", going clear back to the
earliest flavors of SmallTalk (at least). Console.WriteLine, as well as you
HelloWorld.Main are what's known in .NET (and C++) lingo as static methods -
or "class methods" in SmallTalk. Such functions belong to a class
(HelloWorld), but can be called without an instance of that class since
they're "class methods".

-cd

[quoted text, click to view]

Yes, .NET is fully OO but a selfrespecting language, also must support
static methods (because of class factories for instance).

But Java uses the *same* idea! How in the universe, would the runtime where
to **start** if the Main method is not static?

[quoted text, click to view]

You are using VB.NET. The code below, is inside a visual basic module. By
definition, all methods in a module are static, and that's why your 'Main'
method is executable.

(if you want a real understandable OO language, use C#, and now I'm having
some people looking angry at me!)



[quoted text, click to view]

These are all static methods. Static methods are not bad at all, only, use
them well.

I'll explain you why. If a method is static, you cannot instantiate it
right? (using Console myCons = new Console) etc

But why on earth do you want to open more than 1 console if there is only
one console -per process-?


Take this code below. It's using StreamWriter which implements the abstract
class TextWriter. Here you have your OO.

class Test
{
public static void Main()
{
// Create an instance of StreamWriter to write text to a file.
// The using statement also closes the StreamWriter.
using (StreamWriter sw = new StreamWriter("TestFile.txt"))
{
// Add some text to the file.
sw.Write("This is the ");
sw.WriteLine("header for the file.");
sw.WriteLine("-------------------");
// Arbitrary objects can also be written to the file.
sw.Write("The date is: ");
sw.WriteLine(DateTime.Now);
}
}
}

Correct me if I am wrong. In an Object Oriented environment each and
everything are objects. That means we cannot directly instantiate a class
nor we can directly reference a member belongs to a class i.e.
ClassName.MethodName ()

If I am right in that sense, we are doing the just opposite in .NET.

For example in the sample Hello World Application given below



Imports System

Class HelloWorld

Public Shared Sub Main ()

Console.WriteLine (“Hello World”)

End Sub

End Class





As per MSDN Console is a Class defined inside the System Namespace. Here we
are directly calling the Method () defined inside the Class Console. How is
this possible in an OO environment?



Reny

[quoted text, click to view]

Not that it really matters, but no it clearly says Class.


Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com

[quoted text, click to view]

You are wrong on a number of points, actually.

[quoted text, click to view]

Not necessarily - languages like C++ or Delphi are hybrids. You can
have fully object-oriented code, but you can also have flat functions
and global variables. .NET could get away with a full object
orientation because it didn't have to be backward compatible.

[quoted text, click to view]

No. Encapsulation does not mean that everything is private; it means
that you have full control over visibility. You can make
implementation internals private, while building a public face that
other classes can see. The public face is outsiders can rely on; the
private members are details that are subject to change.

[quoted text, click to view]

A public method.

--

<http://www.midnightbeach.com> Contracting, consulting, training

..NET 2.0 for Delphi Programmers <http://www.midnightbeach.com/.net>

You are confusing the purists definition of Object Orientation with the much
more usable definition implemented in .NET. The purist definition requires,
among other things, that all methods of a class be associated with an
instance of that class. The reality is that this makes a language nearly
impossible to work with. The pragmatic approach, in this particular case,
is to allow class methods that don't require an instance of the class.
Note, however, that a class method (Static in C# and C++ and Public Shared
in VB) cannot refer to any private implementation of the class as this would
then require that an object be instantiated for that class.

Having worked in a pure OO environment and in the mixed OO/Procedural
environment of .NET, I'll take the mixed environment any day at it resolves
the OO issue of excessively deep object trees that become nearly as hard to
debug as speghetti code.

Mike Ober

[quoted text, click to view]

[quoted text, click to view]

you are right.

This is because Sub Main is -shared- (this is the same as static)

Public Shared Sub Main ()

Console.WriteLine ("Hello World")

End Sub


If you would put Sub main in a module, the shared attribute would not be
needed.