Why it's impossible to have a static indexer in C#?
-
-
Re: Static indexers
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.
--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
Bring the power of unit testing to VS .NET IDE
"Sergey Klementiev" <sklementiev@by te-et.ru> wrote in message
news:OM2yFoz2DH A.1760@TK2MSFTN GP10.phx.gbl...[color=blue]
> Why it's impossible to have a static indexer in C#?
>
>[/color]
-
Re: Static indexers
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
Read my Blog at http://bobpowelldotnet.blogspot.com
"Sergey Klementiev" <sklementiev@by te-et.ru> wrote in message
news:OM2yFoz2DH A.1760@TK2MSFTN GP10.phx.gbl...[color=blue]
> Why it's impossible to have a static indexer in C#?
>
>[/color]
Comment
-
Re: Static indexers
Bob Powell [MVP] <bob@_spamkille r_bobpowell.net > wrote:[color=blue]
> An indexer will access some instance data. Static methods and properties may
> not access instance data so there's no point in having one.[/color]
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.GetEnc oding(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.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Static indexers
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.
"Sergey Klementiev" <sklementiev@by te-et.ru> wrote in message
news:OM2yFoz2DH A.1760@TK2MSFTN GP10.phx.gbl...[color=blue]
> Why it's impossible to have a static indexer in C#?
>
>[/color]
Comment
-
Re: Static indexers
"Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in message
news:OYFNpB82DH A.2308@TK2MSFTN GP11.phx.gbl...[color=blue]
> Indexers are intended as a way to make your instance behave as if it was[/color]
an[color=blue]
> 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?[/color]
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
Comment
-
Re: Static indexers
"Eric Gunnerson [MS]" <ericgu@online. microsoft.com> wrote in message
news:OYFNpB82DH A.2308@TK2MSFTN GP11.phx.gbl...[color=blue]
> Indexers are intended as a way to make your instance behave as if it was[/color]
an[color=blue]
> 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?
>[/color]
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.[color=blue]
> --
> 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[/color]
rights.[color=blue]
> "Sergey Klementiev" <sklementiev@by te-et.ru> wrote in message
> news:OM2yFoz2DH A.1760@TK2MSFTN GP10.phx.gbl...[color=green]
> > Why it's impossible to have a static indexer in C#?
> >
> >[/color]
>
>[/color]
Comment
-
Re: Static indexers
Daniel O'Connell <onyxkirx@--NOSPAM--comcast.net> wrote:[color=blue]
> 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.[/color]
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.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Static indexers
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.Crea te), 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).
--
Justin Rogers
DigiTec Web Consultants, LLC.
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a71b5 ec5bf1c64a989e6 8@msnews.micros oft.com...[color=blue]
> Daniel O'Connell <onyxkirx@--NOSPAM--comcast.net> wrote:[color=green]
> > 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.[/color]
>
> 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.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]
Comment
-
Re: Static indexers
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a71b5 ec5bf1c64a989e6 8@msnews.micros oft.com...[color=blue]
> Daniel O'Connell <onyxkirx@--NOSPAM--comcast.net> wrote:[color=green]
> > The immediate usage that comes to mind, for me, are static classes[/color][/color]
somewhat[color=blue][color=green]
> > 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[/color][/color]
array, a[color=blue][color=green]
> > piece of memory that simply exists with a set of values in it. I can see[/color][/color]
it[color=blue][color=green]
> > conceptually. Although the functionality can easily be managed using a
> > static array or IList property, there is the question of why a static[/color][/color]
type[color=blue][color=green]
> > 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[/color][/color]
shouldn't[color=blue][color=green]
> > be allowed to act as an array, when appropriate.
> > Mind you, this is an issue of conceptuallity, and I would need a fair[/color][/color]
bit of[color=blue][color=green]
> > convincing myself that the feature is really useful(or proper, but thats[/color][/color]
a[color=blue][color=green]
> > whole nother can of worms), I just can't find a reason why the concept
> > doesn't work.[/color]
>
> 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.
>[/color]
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.
[color=blue]
> I think named indexers are a far more pressing issue, myself.[/color]
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.[color=blue]
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]
Comment
-
Re: Static indexers
Justin Rogers <Justin@games4d otnet.com> wrote:[color=blue]
> 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.[/color]
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.
[color=blue]
> The largest use for static indexers would be as factories.[/color]
Agreed.
[color=blue]
> 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).[/color]
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.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
-
Re: Static indexers
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.
"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a71b5 ec5bf1c64a989e6 8@msnews.micros oft.com...[color=blue]
> Daniel O'Connell <onyxkirx@--NOSPAM--comcast.net> wrote:[color=green]
> > The immediate usage that comes to mind, for me, are static classes[/color][/color]
somewhat[color=blue][color=green]
> > 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[/color][/color]
array, a[color=blue][color=green]
> > piece of memory that simply exists with a set of values in it. I can see[/color][/color]
it[color=blue][color=green]
> > conceptually. Although the functionality can easily be managed using a
> > static array or IList property, there is the question of why a static[/color][/color]
type[color=blue][color=green]
> > 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[/color][/color]
shouldn't[color=blue][color=green]
> > be allowed to act as an array, when appropriate.
> > Mind you, this is an issue of conceptuallity, and I would need a fair[/color][/color]
bit of[color=blue][color=green]
> > convincing myself that the feature is really useful(or proper, but thats[/color][/color]
a[color=blue][color=green]
> > whole nother can of worms), I just can't find a reason why the concept
> > doesn't work.[/color]
>
> 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.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]
Comment
-
Re: Static indexers
Eric Gunnerson [MS] <ericgu@online. microsoft.com> wrote:[color=blue]
> 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.[/color]
I suspect they're using factory methods, just as Encoding.GetEnc oding
does - and that it's factories which would be the principle benefactor
of it.
[color=blue]
> If that makes sense...[/color]
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...
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
Comment
Comment