Why are there no indexed properties?

[Russell Bearden]

Why are there no indexed properties in C#?

For example:

class blah
{
public Node Child[index]
{
get
{
..... some code
return someNode[index];
}
set
{
... some code
someNode[index] = value;
}
}

I prefer to not return a reference to the entire data structure containing
the nodes. Also, doing so prevents me from having much control over
exactly what I am returning, unless it is always just blatantly
someNode[index].

 

[Frank Oquendo]

Why are there no indexed properties in C#?

There is but you only get one:

this[index]

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Peter Rilling]

Well, there are indexers.

public Node this[index]{
...
}

You can even overload the indexers

public Node this[index, str]{
...
}

Indexers compile into properties in the CLR.

 

[cody]

Well, there are indexers.

public Node this[index]{
...
}

You can even overload the indexers

public Node this[index, str]{
...
}

Indexers compile into properties in the CLR.

No, he was asking for "Named Indexers". Such a thing does not exist in C#
and I wonder why, since in VB.NET they are there.
It would be a great thing having them in C#, they would make things a lot
easier.

 

[Peter Rilling]

I know there is a difference between properties with parameters and indexer.
I am also familiar with the VB method of doing things.

His example implied the use of indexers (although me may not have been aware
of such a construct). He wanted something like "return someNode[index]"
which is the exact syntax for indexers. Now, I do not know what you mean by
named indexers since C# does not use the name of the index property anyway
(the property by default is named Item). You can change the name that other
systems see by using IndexNameAttribute.

Well, there are indexers.

public Node this[index]{
...
}

You can even overload the indexers

public Node this[index, str]{
...
}

Indexers compile into properties in the CLR.

No, he was asking for "Named Indexers". Such a thing does not exist in C#
and I wonder why, since in VB.NET they are there.
It would be a great thing having them in C#, they would make things a lot
easier.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

The OP wanted to have functionality like this:

NodeChild nc = myNode.Child[10];

Without having to return an array. What he wanted, was a named indexer, not
the anonymous one that C# provides.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

I know there is a difference between properties with parameters and indexer.
I am also familiar with the VB method of doing things.

His example implied the use of indexers (although me may not have been aware
of such a construct). He wanted something like "return someNode[index]"
which is the exact syntax for indexers. Now, I do not know what you mean by
named indexers since C# does not use the name of the index property anyway
(the property by default is named Item). You can change the name that other
systems see by using IndexNameAttribute.

Well, there are indexers.

public Node this[index]{
...
}

You can even overload the indexers

public Node this[index, str]{
...
}

Indexers compile into properties in the CLR.

No, he was asking for "Named Indexers". Such a thing does not exist in C#
and I wonder why, since in VB.NET they are there.
It would be a great thing having them in C#, they would make things a lot
easier.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Bjorn Abelli]

"cody" ...

No, he was asking for "Named Indexers". Such a thing
does not exist in C# and I wonder why, since in VB.NET
they are there. It would be a great thing having them
in C#, they would make things a lot
easier.

Though it's a bit of a hassle, you can create the similar behaviour, by just
adding another level of indirection (I believe there's a thread on the
indirection subject somewhere too).


class blah
{

Child theChild;

...

public Node Child
{
get
{
return theChild;
}
}
}


class Child
{

SomeNodeCollection children;

...

public Node this[index]
{
get
{
return children[index];
}
set
{
children[index] = value;
}
}
}

So to implement the behaviour the OP asked for wouldn't make anything
easier, but this would at least hide the reference to the actual collection,
and instead return a wrapper to the collection.

// Bjorn A

 

[Morten Wennevik]

The OP wanted to have functionality like this:

NodeChild nc = myNode.Child[10];

Without having to return an array. What he wanted, was a named indexer,
not
the anonymous one that C# provides.

I believe that is the Visual Basic way of doing it as myNode.Child(10)
(VB) would translate to myNode[10] (C#)
Same with things having a Thingy.Item(x) (VB) -> Thingy[10] (C#)

I could be very wrong.

 

[Rob Teixeira [MVP]]

There are only two problems with this translation from VB.
1) you aren't looking for the 10th node (which is what the code looks like
it's trying to do. can you tell by the C# indexer consumer code if you are
trying to get the 10th child vs the 10th sibling, for example?), you're
looking for the 10th Child on a node. The C# indexer can get confusing if
you aren't allowed to specify a non-default name
2) becaue the indexers aren't named in C#, you can't have more than one (you
can only override the default one, but that doesn't allow for certain
property semantics). this is silly, because behind the scenes, C# is in fact
creating a named property in IL, and applying the "default" meta-tag to it.
It wouldn't be too much work to create named properties with arguments that
don't have the "default meta-tag, as VB does.

However the above two issues are more along the lines of theory with regards
to the absense of named parameters with arguments - a better way to solve
the actual problem in this particular example as you have presented it
(which works fine in C#) is to create a readonly Child property on the node,
which is of type Nodes (a collection of Node), and have an indexer on *it*.
That allows you to use:

myNode.Child[10]
instead of
myNode[10]

-Rob Teixeira [MVP]

The OP wanted to have functionality like this:

NodeChild nc = myNode.Child[10];

Without having to return an array. What he wanted, was a named indexer,
not
the anonymous one that C# provides.

I believe that is the Visual Basic way of doing it as myNode.Child(10)
(VB) would translate to myNode[10] (C#)
Same with things having a Thingy.Item(x) (VB) -> Thingy[10] (C#)

I could be very wrong.