current type in static methods

[Jon Skeet [C# MVP]]

I agreed that the encoding class could benefit from static indexers but
generally I don't like indexers for uses like that.

You seem to be inconsistent here: either the Encoding class would
benefit from it, *or* (as you said before) it doesn't fit. I don't see
how you can have it both ways, being both a good thing and a bad thing
at the same time.

In my opinion as I said, indexers should only be used when writing
wrappers for array like classes like matrices.

I think that's a bit of a narrow usage pattern, myself. Does Hashtable
fit into that? It's not really an array-like class, in that the index
isn't necessarily a number...

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.

So you don't like dataRow[columnName, DataRowVersion.Current] either?

It seems pretty reasonable to me.

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

Sure, they can write bad code. Then again, they could write every
method with the same name instead, which is just as bad.

 

[codymanix]

I agreed that the encoding class could benefit from static indexers but

You seem to be inconsistent here: either the Encoding class would
benefit from it, *or* (as you said before) it doesn't fit. I don't see
how you can have it both ways, being both a good thing and a bad thing
at the same time.

No Iam not inconsistent:

1. My Personal Opinion is that Indexers are a good thing for Arrays,Matrices
and similar and should not used for other things.

2. The .NET Framework uses indexers for everything that is like a collection
or could at least be understood as a collection so using an indexer for the
Encoding would fit to the rest of the Framework and would be consistent.

You only have to distinguish between my Opinion and the Opinion of Microsoft

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.

So you don't like dataRow[columnName, DataRowVersion.Current] either?

It seems pretty reasonable to me.

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

Sure, they can write bad code. Then again, they could write every
method with the same name instead, which is just as bad.

Indeed.

 

[Daniel O'Connell [C# MVP]]

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.

Which misses my point entirely. I was suggesting the usage of class as a
pointer similar to this, instead of as a type explictly, typeof(class) may
or may not make sense in this particular situation.

Personally, typeof(class) is far to limited to be a feature on its own. It
introduces a use of class that is inconsistent with the rest of hte
langauge.

 

[codymanix]

And what would you consider this to mean?

should
it


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

[..]
Which misses my point entirely. I was suggesting the usage of class as a
pointer similar to this, instead of as a type explictly, typeof(class) may
or may not make sense in this particular situation.

Personally, typeof(class) is far to limited to be a feature on its own. It
introduces a use of class that is inconsistent with the rest of hte
langauge.

either we say that in *both* static and instance methods we can say
typeof(this) and this.DoIt()
or we say in static methods we must use typeof(class) and class.DoIt()
instead.

these are the options. the first option alters the meaning of the "this"
keyword which is not good.
the latter would allow the existing keyword "class" to be used within
methods where it was disallowed up to this time.