S
Sergey Klementiev
Why it's impossible to have a static indexer in C#?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
Dmitriy Lapshin [C# / .NET MVP]
My guess is that's because only one indexer is allowed in C#, and it is
referenced with the "this" keyword, you cannot have it static since "this"
is meaningless when no instances are available. More than that, this would
prevent having static and non-static indexer at the same time.
referenced with the "this" keyword, you cannot have it static since "this"
is meaningless when no instances are available. More than that, this would
prevent having static and non-static indexer at the same time.
B
Bob Powell [MVP]
An indexer will access some instance data. Static methods and properties may
not access instance data so there's no point in having one.
--
Bob Powell [MVP]
C#, System.Drawing
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm
Read my Blog at http://bobpowelldotnet.blogspot.com
not access instance data so there's no point in having one.
--
Bob Powell [MVP]
C#, System.Drawing
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm
Read my Blog at http://bobpowelldotnet.blogspot.com
J
Jon Skeet [C# MVP]
Bob Powell said:An indexer will access some instance data. Static methods and properties may
not access instance data so there's no point in having one.
An indexer doesn't conceptually *have* to access some instance data
though, any more than a property does - and you can have static
properties. For instance, Encoding.GetEncoding(string) could be made
(conceptually) into an indexer so that you could use
Encoding["ASCII"] etc if you wanted.
As far as I can understand it's allowed by the ECMA spec, although
admittedly I haven't been able to fudge up an example. I suspect it's
disallowed due to the syntax being a bit odd and it not being useful
very often.
E
Eric Gunnerson [MS]
Indexers are intended as a way to make your instance behave as if it was an
array, and static indexers are outside of that usage.
They could be added, but we'd have to be convinced that their utility was
worth the additional complexity. What do you want to use them for?
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
array, and static indexers are outside of that usage.
They could be added, but we'd have to be convinced that their utility was
worth the additional complexity. What do you want to use them for?
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
S
Sergey Klementiev
Eric Gunnerson said:Indexers are intended as a way to make your instance behave as if it was an
array, and static indexers are outside of that usage.
They could be added, but we'd have to be convinced that their utility was
worth the additional complexity. What do you want to use them for?
For example for key or index-based instance access. Such helper would be
very useful, imho.
SomeClass o = SomeClass[key, ...];
Currency c = Currency["USD"];
Vehicle v = Vehicle["Ford", "Mustang", "1997"]
WBR,
Sergey Klementiev
MCSD EA
D
Daniel O'Connell
Eric Gunnerson said:Indexers are intended as a way to make your instance behave as if it was an
array, and static indexers are outside of that usage.
They could be added, but we'd have to be convinced that their utility was
worth the additional complexity. What do you want to use them for?
The immediate usage that comes to mind, for me, are static classes somewhat
simliar to lookup tables I used to use in C, a global, static, readonly
array. A type with a static indexer could be considered as a static array, a
piece of memory that simply exists with a set of values in it. I can see it
conceptually. Although the functionality can easily be managed using a
static array or IList property, there is the question of why a static type
cannot appear as an array, after all there are static methods, static
properties, static events, etc etc, a static can look like an instance
object in most other respects, I wonder if there is a reason one shouldn't
be allowed to act as an array, when appropriate.
Mind you, this is an issue of conceptuallity, and I would need a fair bit of
convincing myself that the feature is really useful(or proper, but thats a
whole nother can of worms), I just can't find a reason why the concept
doesn't work.
J
Jon Skeet [C# MVP]
Daniel O'Connell said:The immediate usage that comes to mind, for me, are static classes somewhat
simliar to lookup tables I used to use in C, a global, static, readonly
array. A type with a static indexer could be considered as a static array, a
piece of memory that simply exists with a set of values in it. I can see it
conceptually. Although the functionality can easily be managed using a
static array or IList property, there is the question of why a static type
cannot appear as an array, after all there are static methods, static
properties, static events, etc etc, a static can look like an instance
object in most other respects, I wonder if there is a reason one shouldn't
be allowed to act as an array, when appropriate.
Mind you, this is an issue of conceptuallity, and I would need a fair bit of
convincing myself that the feature is really useful(or proper, but thats a
whole nother can of worms), I just can't find a reason why the concept
doesn't work.
As a concept I'm sure it does work. I believe what Eric was saying
(correct me if I'm wrong, Eric!) is that the occasionally useful time
isn't worth the extra complexity of language in terms of syntax not
only for declaring it in the first place (static this doesn't sound
good, IMO, even if it's the logical extension) but also accessing the
indexer when it's set up. If no other languages support it, that would
also be a problem - it's much less useful to have a feature which only
C# can access.
I think named indexers are a far more pressing issue, myself.
J
Justin Rogers
I think the feature is more than occasionally useful. However, I don't feel
that there
aren't ways to simply work around, and easily work around, the times where you
might use the feature. However, in my case, I tend to think named indexers have
the
same issue. A named indexer is easy to work around by extending a property of a
given class that is itself indexed.
The largest use for static indexers would be as factories. Simple cached access
to class
instances by a series of parameter values that describe how to find the class,
and if it
doesn't exist, how to create it. The same goal can be accomplished with a
static function
(look at WebRequest.Create), that internally stores a Hashtable to hold onto
cached classes.
I'm up in the air on this one. Features are nice, but I'm all about the
performance. If adding
named indexers or static indexers in at the language level is going to be faster
and more
performant that me using a class with a default indexed property or a static
creation function
backed by a Hashtable then give it to me, because I want the speed. In this
case the only
feature I can see actually being faster is the named indexer since it'll get rid
of a property
look-up (that I could have made a public read-only field anyway).
that there
aren't ways to simply work around, and easily work around, the times where you
might use the feature. However, in my case, I tend to think named indexers have
the
same issue. A named indexer is easy to work around by extending a property of a
given class that is itself indexed.
The largest use for static indexers would be as factories. Simple cached access
to class
instances by a series of parameter values that describe how to find the class,
and if it
doesn't exist, how to create it. The same goal can be accomplished with a
static function
(look at WebRequest.Create), that internally stores a Hashtable to hold onto
cached classes.
I'm up in the air on this one. Features are nice, but I'm all about the
performance. If adding
named indexers or static indexers in at the language level is going to be faster
and more
performant that me using a class with a default indexed property or a static
creation function
backed by a Hashtable then give it to me, because I want the speed. In this
case the only
feature I can see actually being faster is the named indexer since it'll get rid
of a property
look-up (that I could have made a public read-only field anyway).
D
Daniel O'Connell
Jon Skeet said:As a concept I'm sure it does work. I believe what Eric was saying
(correct me if I'm wrong, Eric!) is that the occasionally useful time
isn't worth the extra complexity of language in terms of syntax not
only for declaring it in the first place (static this doesn't sound
good, IMO, even if it's the logical extension) but also accessing the
indexer when it's set up. If no other languages support it, that would
also be a problem - it's much less useful to have a feature which only
C# can access.
With this I mostly agree, I was more at odds with the statement that
indexers were out of their intended usage(and thereby the concept) at the
type level. I feel the concept and usage is valid, even if the...I guess you
could say value of the usage may not be. There are a great many features in
the language already that greatly increase complexity for rare usage(like
most operator overloading), but that is irrelevent. I don't mean to imply
there is a need for the feature, simply that I think it works from an
expectation standpoint.
I think named indexers are a far more pressing issue, myself.
On this I agree, named indexers(or prarameterized properties) are useful and
would possibly be a good addition to the language, although I fear they will
be abused and used in situations where a method is more appropriate.
However, named indexers starts to give you a decent argument for static
indexers. It would allow you to write static accessor code without having to
write an extra class or relying on dictionaries or lists. Of course, these
indexers being just parameterized properties mitigates that, It would be
confusing however if they were called named indexers and permitted to be
static while unnamed indexers are not. That is more of a naming issue than
anything else.
Btw, while I agree that static this seems wrong, I would think it would be
more appropriate to be...
public object static[string key]
{
get{}
set{}
}
than to use static this. It just seems far clearer to me than any other
possibility, even if it adds another usage for static.
J
Jon Skeet [C# MVP]
Justin Rogers said:I think the feature is more than occasionally useful. However, I don't feel
that there aren't ways to simply work around, and easily work around, the times
where you might use the feature. However, in my case, I tend to think named
indexers have the same issue. A named indexer is easy to work around by extending
a property of a given class that is itself indexed.
Do you mean by making a property return an indexed class? Yes, that
works - but it's a real pain to create a new type of collection each
time, etc - and you might want it to be readonly, etc.
The largest use for static indexers would be as factories.
Agreed.
I'm up in the air on this one. Features are nice, but I'm all about the
performance. If adding named indexers or static indexers in at the language level
is going to be faster and more performant that me using a class with a default
indexed property or a static creation function
backed by a Hashtable then give it to me, because I want the speed. In this
case the only feature I can see actually being faster is the named indexer since
it'll get rid of a property
look-up (that I could have made a public read-only field anyway).
I don't believe any of them have any significant performance
differences, to be honest, when JIT inlining is taken into account. I'm
inclined the other way - get a nice design first, and worry about
performance later (on this scale) if it ends up being an issue.
E
Eric Gunnerson [MS]
Yes, that's pretty much what I meant. I'm trying to understand how people
would use them and what they're using now instead of static indexers to
figure out how useful people would find them.
If that makes sense...
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
would use them and what they're using now instead of static indexers to
figure out how useful people would find them.
If that makes sense...
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
J
Jon Skeet [C# MVP]
Eric Gunnerson said:Yes, that's pretty much what I meant. I'm trying to understand how people
would use them and what they're using now instead of static indexers to
figure out how useful people would find them.
I suspect they're using factory methods, just as Encoding.GetEncoding
does - and that it's factories which would be the principle benefactor
of it.
If that makes sense...
Absolutely. While we're on the topic, however - are named indexers
being looked at for a future version of C#? I really want to be able to
do things like:
byte[] data;
public byte Data[int index]
{
get { return data[index]; }
}
rather than coming up with a new class just to give that read-only
strongly-typed array indexing. I suppose (as with so many things)
generics will help there anyway, and then a Length property would be
exposed too...