c# functions

[Mark]

are there functions in c# for just members of a class
myclass.Method/function

Thanks
Mark

 

[Robson Siqueira]

I think this is not clear for me. Would you please specify better?

 

[Chris Dunaway]

are there functions in c# for just members of a class
myclass.Method/function

Are you referring to a static method?

public class MyClass
{
public static void SomeMethod()
{
//do something here
}
}


Call this method with:

MyClass.SomeMethod();

 

[Mark]

Example in other languages.....
there could be a function declaration

Function int myfunc()
///do somthing
return
vb6
private function myfunc()
'// do somthing
myfunc=true
end function
is there functions like the above that do not belong as member in a class
Or

is c# Class Driven only
public myclass
{
public int myfunc()
{
// do somthing
return 0
}
}
// main app
myclass = new myclass().myfunc()

thanks
Mark

 

[Bob Powell [MVP]]

Global methods or functions are mot possible. They must all be members
of a class even if that class is static.

FYI This sort of programming methodology is incredibly bad practice.
Static functions should be avoided at all cost or at least kept to
nothing more complex than the program entry point.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Bob Powell [MVP]]

I meant to say "Even if that _method_ is static"
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Ben Voigt]

Global methods or functions are mot possible. They must all be members of
a class even if that class is static.

FYI This sort of programming methodology is incredibly bad practice.
Static functions should be avoided at all cost or at least kept to nothing
more complex than the program entry point.

Baloney. This whole idea that C# and Java have that log10, sin, etc, have
to be members of a Math class is ludicrous and adds nothing to readability
or maintainability. Insisting on having an object instance to call such
functions to "avoid static functions at all cost" is insane.

 

[Jon Skeet [C# MVP]]

Baloney. This whole idea that C# and Java have that log10, sin, etc, have
to be members of a Math class is ludicrous and adds nothing to readability
or maintainability. Insisting on having an object instance to call such
functions to "avoid static functions at all cost" is insane.

I would say that forcing methods to be part of classes is good, but
avoiding static methods is a bad idea. So I'm against *global* methods,
but have no problem with *static* methods (where appropriate, of
course).

 

[Ben Voigt]

I would say that forcing methods to be part of classes is good, but
avoiding static methods is a bad idea. So I'm against *global* methods,
but have no problem with *static* methods (where appropriate, of
course).

For reasons of dealing with name collisions, you usually want such functions
to be namespace members and not global. But you absolutely should be able
to import the entire group en masse with "using namespace ..." or the
equivalent, and then be able to use undecorated names. Perhaps the answer
is to unify namespaces and classes, providing a using directive that imports
static members of a class into scope. But there ought to be some way to
call functions without explicitly specifying the scope. Currently, C# only
lets you have this friendly use of static members of a single class, and
that uses up your single inheritance, and doesn't work with sealed classes
(including static classes).

 

[Jon Skeet [C# MVP]]

For reasons of dealing with name collisions, you usually want such functions
to be namespace members and not global. But you absolutely should be able
to import the entire group en masse with "using namespace ..." or the
equivalent, and then be able to use undecorated names. Perhaps the answer
is to unify namespaces and classes, providing a using directive that imports
static members of a class into scope.

That's what Java did (although it didn't really "unify namespaces and
classes" - just allowed importing of all static members). I certainly
wouldn't object to C# gaining that feature. I don't tend to use it much
in Java, but occasionally it can be very useful - calls to Math.* are a
good example.

But there ought to be some way to
call functions without explicitly specifying the scope. Currently, C# only
lets you have this friendly use of static members of a single class, and
that uses up your single inheritance, and doesn't work with sealed classes
(including static classes).

Inheritance shouldn't be used for that anyway, IMO.

 

[Bruce Wood]

For reasons of dealing with name collisions, you usually want such functions
to be namespace members and not global. But you absolutely should be able
to import the entire group en masse with "using namespace ..." or the
equivalent, and then be able to use undecorated names. Perhaps the answer
is to unify namespaces and classes, providing a using directive that imports
static members of a class into scope. But there ought to be some way to
call functions without explicitly specifying the scope.

But with any feature like this, I have to ask, what does it gain for
me, in return for making the compiler / language more complicated.

In this case, my answer is, "Practically nothing." Perhaps it's
because I'm a touch typist, but being able to type Sin instead of
Math.Sin seems to me a finesse, a minor touch. To re-jig the whole way
that names work in C# to accommodate seems, IMHO, to be akin to
killing a fly with a shotgun.

 

[Bruce Wood]

Example in other languages.....
there could be a function declaration

Function int myfunc()
///do somthing
return
vb6
private function myfunc()
'// do somthing
myfunc=true
end function
is there functions like the above that do not belong as member in a class
Or

is c# Class Driven only
public myclass
{
public int myfunc()
{
// do somthing
return 0}
}

// main app
myclass = new myclass().myfunc()

This is not necessary.

public myclass
{
public static int myfunc()
{
// do something
return 0;
}
}

// main app
int foo = myclass.myfunc();

By specifying "static", it becomes unnecessary to "new" an instance
just to call the method.

 

[Jon Skeet [C# MVP]]

But with any feature like this, I have to ask, what does it gain for
me, in return for making the compiler / language more complicated.

In this case, my answer is, "Practically nothing." Perhaps it's
because I'm a touch typist, but being able to type Sin instead of
Math.Sin seems to me a finesse, a minor touch. To re-jig the whole way
that names work in C# to accommodate seems, IMHO, to be akin to
killing a fly with a shotgun.

It's not a case of being able to just *type* Sin instead of Math.Sin -
it's a case of reading it. In a maths-intensive method where each line
contains four calls to methods in the Math class which are *obviously*
in the Math class, the readability difference is significant:

double x = Cos(theta)*Sin(beta) + Sin(theta)*Cos(beta);
vs
double x = Math.cos(theta)*Math.sin(beta) +
Math.Sin(theta)*Math.cos(beta);

I know which I find more readable.

 

[Mark]

Thanks Bruce
the Static clears up alot....
Since Static can be used under many circumstances
Mark