current type in static methods

[cody]

Often you want to get the type of the current class in a static method.
since in static methods you cannot call GetType(), you have to go for
typeof(MyClass). But the problem now is, that this does not make the intend
really clear that you mean the "current class".
I you have to refactor your code, move this method or rename the class you
will run into problems.
Thats why i suggest a new language feature: "typeof (class)". since class
is
already a keyword, no new keywords are needed. What do you think?

public class MyClass
{
public static DoIt()
{
Console.WriteLine("Iam declared in class: " + typeof (class));
}
}

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Cody,

What is wrong with typeof(MyClass) ?

Remember that a static method belong to the type, not to a instance,
therefore if you needs to get a reference to the Type of where that method
is defined you for sure know the type of it.

If you move that code to an instance method, then you can get the type of
the instance using GetType() or may still use the type of the class itself
using typeof(MyClass ) , so if you move the code to an instance method more
likely you still want the same result that if you were in a static method.

Cheers,

 

[cody]

What is wrong with typeof(MyClass) ?

a lot is wrong with it. consider this:

public class Panel
{
private static void InitializeComponent()
{
System.Resources.ResourceManager resources = new
System.Resources.ResourceManager(typeof(Panel));
}
}

You declare a class named Panel (remember there already exists a clas named
panel in the .Net framework).
Now you rename your class into MyPanel. in the code there still ist
ypeof(Panel). Your code still compiles but
it won't load the correct resources for your control.

using a syntax like "typeof(class)" would be much clearer, to show the
intend: you mean the *current* class, the declaring class of that method.
this would be easier readable.

 

[Mattias Sjögren]

Often you want to get the type of the current class in a static method.

I'm not sure I can agree with "often" - I've never had to do it. But
anyway, I believe this should work and be

Console.WriteLine("Iam declared in class: " +
MethodBase.GetCurrentMethod().DeclaringType );



Mattias

 

[codymanix]

Often you want to get the type of the current class in a static method.

I'm not sure I can agree with "often" - I've never had to do it. But
anyway, I believe this should work and be

Console.WriteLine("Iam declared in class: " +
MethodBase.GetCurrentMethod().DeclaringType );

Thank you, I didn't know that, it works. But anyway, I find that

"System.Reflection.MethodBase.GetCurrentMethod().DeclaringType"

is less elegant then just writing

"typeof(class)"

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Cody,

See my comments inline.

You declare a class named Panel (remember there already exists a clas named
panel in the .Net framework).
Now you rename your class into MyPanel. in the code there still ist
ypeof(Panel). Your code still compiles but
it won't load the correct resources for your control.

You should NEVER rename a class once you have deployed it, it can ( I
think I can say it will) break any code that use it in the first place, if
you need to add/change functionality, inherit, that's why it exist.

using a syntax like "typeof(class)" would be much clearer, to show the
intend: you mean the *current* class, the declaring class of that method.
this would be easier readable.

Yes, that's correct but it only adds more complexity to the language , to
the compiler ( it has to decide which of the meaning of the expression use
at a given moment) and it will also difficult to a person reading the code
that would have to check how the method is declared to know which meaning
the expression has.

You see, I read somewhere ( gotdotnet.com IIRC ) that one of the designers
of C# said that with a language the most difficult part is decide what left
outside of it.



Cheers,

 

[codymanix]

You should NEVER rename a class once you have deployed it, it can ( I

think I can say it will) break any code that use it in the first place, if
you need to add/change functionality, inherit, that's why it exist.

Agreed when its is a library. If it is just an application then it is imho
ok.

Yes, that's correct but it only adds more complexity to the language , to
the compiler ( it has to decide which of the meaning of the expression use
at a given moment) and it will also difficult to a person reading the code
that would have to check how the method is declared to know which meaning
the expression has.

typeof(class) would be no special functionality it would just a language
keyword that is substituted by the compiler with
"MethodBase.GetCurrentMethod().DeclaringType", just as lock (myObject)
simply is a substitution for Monitor.Enter(myObject).

You see, I read somewhere ( gotdotnet.com IIRC ) that one of the designers
of C# said that with a language the most difficult part is decide what left
outside of it.

Agreed, but not in this example.

 

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

You should NEVER rename a class once you have deployed it, it can ( I
think I can say it will) break any code that use it in the first place, if
you need to add/change functionality, inherit, that's why it exist.

I don't think cody had actually suggested that it had been deployed at
this stage... I find it quite common to want to rename classes during
development. Roll on refactoring!

Yes, that's correct but it only adds more complexity to the language , to
the compiler ( it has to decide which of the meaning of the expression use
at a given moment) and it will also difficult to a person reading the code
that would have to check how the method is declared to know which meaning
the expression has.

typeof(class) can never have any other meaning though - it's not a
legal expression as it stands, as class is a reserved word.

You see, I read somewhere ( gotdotnet.com IIRC ) that one of the designers
of C# said that with a language the most difficult part is decide what left
outside of it.

Sure - and I'm not saying it's definitely a good idea. It *does* add
complexity to the language, and it would add to compiler complexity,
but I don't believe it would actually make things less readable. It
would be one more thing to remember, that's all - I don't think it can
actually be confused with any other syntax.

 

[Ignacio Machin \( .NET/ C# MVP \)]

typeof(class) can never have any other meaning though - it's not a
legal expression as it stands, as class is a reserved word.

You are correct, I think I mix two post somehow , I had the idea that the
proposed construction would have a different meaning from used on a static
method and on an instance method.
Maybe this was the first post in the morning and I had not enough cafeine
in blood

Sure - and I'm not saying it's definitely a good idea. It *does* add
complexity to the language, and it would add to compiler complexity,
but I don't believe it would actually make things less readable. It
would be one more thing to remember, that's all - I don't think it can
actually be confused with any other syntax.

Agreed.


Cheers,

 

[codymanix]

You declare a class named Panel (remember there already exists a clas

I don't think cody had actually suggested that it had been deployed at
this stage... I find it quite common to want to rename classes during
development. Roll on refactoring!


typeof(class) can never have any other meaning though - it's not a
legal expression as it stands, as class is a reserved word.


Sure - and I'm not saying it's definitely a good idea. It *does* add
complexity to the language, and it would add to compiler complexity,
but I don't believe it would actually make things less readable. It
would be one more thing to remember, that's all - I don't think it can
actually be confused with any other syntax.

Additionally it could help you with calling members in static methods when
overloading:

class DoIt
{
static void A(int i, bool b)
{
}

static void A(int i)
{
class.A(i, false); // instead of "this." like in instance methods.
}
}

 

[Daniel O'Connell [C# MVP]]

Additionally it could help you with calling members in static methods when
overloading:

class DoIt
{
static void A(int i, bool b)
{
}

static void A(int i)
{
class.A(i, false); // instead of "this." like in instance methods.
}
}

It could also provide syntax for static indexers, simply

static int class[int x]{...};

Not that static indexers always make alot of sense, it stlil solves the
problem of the inconsistency of using this.

More interestingly, however, how should it behave in a non-static method. Do
you think it should be undefined just as this is undefined in a static? Or
should it be a polymorphic way to refer to the current type and its static
members?

 

[codymanix]

Additionally it could help you with calling members in static methods
when

overloading:

class DoIt
{
static void A(int i, bool b)
{
}

static void A(int i)
{
class.A(i, false); // instead of "this." like in instance methods.
}
}

It could also provide syntax for static indexers, simply

static int class[int x]{...};

Not that static indexers always make alot of sense, it stlil solves the
problem of the inconsistency of using this.

More interestingly, however, how should it behave in a non-static method. Do
you think it should be undefined just as this is undefined in a static? Or
should it be a polymorphic way to refer to the current type and its static
members?

A static indexer definitely belongs to the most useless things in a language
I could imagine.
But for the sake of consistency, I agree that there is no reason why they
left it out.
Under the hood in the IL-code I suppose it is simply a call to a static
method and would be
allowed if programmign directly in MSIL, but Iam not sure.

I know of a scripting language for the java platform named "Groovy" which
understands the this keyword in the context of a static method
as a reference to the current class which is similar to my proposal.
So in Groovy the following would be valid:

class A
{
static int s=1234;

static int getS()
{
return this.s; // note usage of this in static mehtod
}
}

 

[Daniel O'Connell [C# MVP]]

Additionally it could help you with calling members in static methods when
overloading:

class DoIt
{
static void A(int i, bool b)
{
}

static void A(int i)
{
class.A(i, false); // instead of "this." like in instance methods.
}
}

It could also provide syntax for static indexers, simply

static int class[int x]{...};

Not that static indexers always make alot of sense, it stlil solves the
problem of the inconsistency of using this.

More interestingly, however, how should it behave in a non-static method. Do
you think it should be undefined just as this is undefined in a static?
Or
should it be a polymorphic way to refer to the current type and its
static
members?

A static indexer definitely belongs to the most useless things in a
language
I could imagine.
But for the sake of consistency, I agree that there is no reason why they
left it out.
Under the hood in the IL-code I suppose it is simply a call to a static
method and would be
allowed if programmign directly in MSIL, but Iam not sure.

I know of a scripting language for the java platform named "Groovy" which
understands the this keyword in the context of a static method
as a reference to the current class which is similar to my proposal.
So in Groovy the following would be valid:

class A
{
static int s=1234;

static int getS()
{
return this.s; // note usage of this in static mehtod
}
}

And what would you consider this to mean?

class A
{
static int s=1234;

int getS()
{
return class.s; //note the use of class here
}
}

My point is more in should class exist within instance methods, or should it
be valid only in static.

 

[Jon Skeet [C# MVP]]

A static indexer definitely belongs to the most useless things in a language
I could imagine.

Consider the Encoding class. It could have had an indexer rather than
Encoding.GetEncoding, which would be pretty nice, IMO.

It's not used very often, but there are certainly times where a static
indexer would be nice. Personally *I'd* use that more often than your
typeof(class), by past experience.

 

[codymanix]

A static indexer definitely belongs to the most useless things in a
language

Consider the Encoding class. It could have had an indexer rather than
Encoding.GetEncoding, which would be pretty nice, IMO.
Agreed!

It's not used very often, but there are certainly times where a static
indexer would be nice. Personally *I'd* use that more often than your
typeof(class), by past experience.

But that doesn't mean it is useless.

 

[Jon Skeet [C# MVP]]

But that doesn't mean it is useless.

Sure - just that I'm disagreeing with your idea that a static indexer
is one of the "most useless things in a language I (you) could
imagine".

 

[codymanix]

I know of a scripting language for the java platform named "Groovy"
which

And what would you consider this to mean?

class A
{
static int s=1234;

int getS()
{
return class.s; //note the use of class here
}
}

My point is more in should class exist within instance methods, or should it
be valid only in static.

if a keyword "class" could be used to identify the current class, it should
be allowed in static *and* instance methods,
because using GetType() or class has a different meaning, so using class in
instance method is useful too:

class A{
public A()
{
Console.WriteLine(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);Console.Write
Line( this.GetType());
}
}

class B:A{}

new B();

Outputs A,B.

GetType() denotes the dynamic type while class (which is a short form for
MethodBase.GetCurrentMethod().DeclaringType) denotes the declaring class.

 

[codymanix]

A static indexer definitely belongs to the most useless things in a

Sure - just that I'm disagreeing with your idea that a static indexer
is one of the "most useless things in a language I (you) could
imagine".

In general I don't like it to use indexers for everything. I agree that it
is useful for array or matrix wrappers
but for Encoding and similar it doesn't fit. What if Encoding[] gets a
second parameter? then you cannot use an indexer anymore.

 

[Jon Skeet [C# MVP]]

In general I don't like it to use indexers for everything. I agree that it
is useful for array or matrix wrappers
but for Encoding and similar it doesn't fit.

Out of interest, why did you agree before then?

What if Encoding[] gets a
second parameter? then you cannot use an indexer anymore.

Yes you can. You could have:

public Encoding this [int number]
{
get { return ...; }
}

public Encoding this [string name]
{
get { return ...; }
}

public Encoding this [string primary, string secondary]
{
get { return ...; }
}

 

[codymanix]

In general I don't like it to use indexers for everything. I agree that
it

Out of interest, why did you agree before then?

I agreed that the encoding class could benefit from static indexers but
generally I don't like indexers for uses like that.
In my opinion as I said, indexers should only be used when writing wrappers
for array like classes like matrices.

What if Encoding[] gets a
second parameter? then you cannot use an indexer anymore.

Yes you can. You could have:

I didn't mean overloading I meant something like that:

int this[int i, string a, double b]
{
get {return GetVal(i,a,b);}
}

I thought that mixing different parameter types would be not possible with
an indexer.
But I was wrong anyway: I tried it and it compiled without problems. If
somebody had asked be before
introducing this feature I'd have said that they should leave it out since
it leads to misuse of indexers.

imagine what happens if a noob discovers that using indexers has the
advantage that you don't have to write method names.
consider a class with 20 overloads of the indexer, every overload does a
completely different task.
welcome to the IOC#CC - international obfuscates c# code contest