Doing some code reading and stumbled upon this snippet that I haven't seen before:
public SomeClass {
public someInterface this[String strParameter] {
get {
return SomeInternalMethod(strParameter);
}
}
}
It looks like it is called as follows:
SomeClass _someClass = new SomeClass();
SomeInterface returnedValue = _someClass["someString"];
I am interested in where this function would be appropriate or what the intent of writing in this style. For example why would this be preferred over simply calling the function?
See the language specification, section 10.9, which states:
An Indexer is a member that enables an object to be indexed in the same way as an array.
Indexers and properties are very similar in concept, but differ in the following ways:
A property is identified by its name, whereas an indexer is identified by its signature.
A property is accessed through a simple-name (§7.5.2) or a member-access (§7.5.4), whereas an indexer element is accessed through an element-access (§7.5.6.2).
A property can be a static member, whereas an indexer is always an instance member.
A get accessor of a property corresponds to a method with no parameters, whereas a get accessor of an indexer corresponds to a method with the same formal parameter list as the indexer.
A set accessor of a property corresponds to a method with a single parameter named value, whereas a set accessor of an indexer corresponds to a method with the same formal parameter list as the indexer, plus an additional parameter named value.
It is a compile-time error for an indexer accessor to declare a local variable with the same name as an indexer parameter.
In an overriding property declaration, the inherited property is accessed using the syntax base.P, where P is the property name. In an overriding indexer declaration, the inherited indexer is accessed using the syntax base[E], where E is a comma separated list of expressions.
It seems like a lot of the answers are focusing on what an indexer is, not why you would want to use one.
As far as I'm concerned, here is the motivation to use an indexer:
You are working on a class that has a collection of some sort, but you want the class to appear to users (consumers of the class) as if it is a collection.
The best example I can think of is the DataRow class in ADO.NET. If you want to get the value of the fifth cell of a DataRow, you can either use DataRow.Item[4] or DataRow[4]. The latter form is a convenient and logical shortcut, and it shows off pretty nicely why you'd want to use an indexer. To the user, the DataRow can be thought of as just a collection of cells (even though it is really more than that), so it makes sense to be able to get and set cell values directly, without having to remember that you are actually getting/setting an Item.
Hope that helps.
In many cases, the 'index' syntax makes a lot of sense. It is particularly useful if the SomeClass represents some sort of collection.
It allows you to do associative array lookups (a.k.a. "dictionary style"), just as you mentioned in your question.
And that's the whole point. Some people like that, particularly people coming from languages that have it built in, like Python or PHP
The "this" keyword is an indexer
from http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx
"Indexers allow instances of a class or struct to be indexed just like arrays. Indexers resemble properties except that their accessors take parameters."
You may have already stumbled across something similar before:
var myList = new List<string>();
myList.Add("One");
myList.Add("Two");
myList.Add("Three");
for(int i = 0; i < myList.Count; i++) {
string s = myList[i];
}
The indexer is the "primary key" of an object that implements a collection. It's just a shorthand way for writing a function like .GetValue(index) - syntactic sugar, if you want. But it also makes the intent clear.
It an implementation of the index operator [ ].
It's an operator overload. Useful if you are writing a collection class for example where it would make sense to access it using array notation, e.g. collection[someIndex].
You could of course write a collection.GetElement(someIndex) function equivalent, but it's a style/readability thing.
Well you could use this method in a key-value pair class.
I am not sure what the analogous class is in c#, but in c++ STL, there is the map class where you call the method with the SomeObject["key"] and it will return the "value" associated with that key.
That's called an Indexer, they allow you to use List<>, ArrayList, Dictionary<> and all the other collections using an array syntax.
It's just syntactic sugar, but it gives some readability when used right.
In my opinion, it's just a syntax convenience.
Where would you NOT use it:
public SomeClass {
private int[] nums;
public GetVal this[int ind] {
get {
return nums[ind]; // this is pointless since array is already indexed
}
}
}
Where would you benefit from it:
public Matrix {
private Dictionary<string, double> matrixData; // Matrix indecies, value
public double this[int row, int col] {
get {
return matrixData[string.Format("{0},{1}", row, col)];
}
}
}
As you can see, for some reason, your data is a Dictionary indexed with a string key and you wish to call this with two integer indecies and still do not want to change your data type:
Matrix m = new Matrix();
...
Console.WriteLine( m[1,2] );
Related
I ran into a problem while doing my job, which is porting software from flash AS3 to .NET/Mono. In AS3 code base I can find many Object declarations that are initialized like this:
private const MAPPING:Object =
{
ssdungf:'flydung',
ssdungt:'flydung',
superfutter:'superfeed'
}
The best option for me would be in C# using anonymous type like this:
var MAPPING = new
{
ssdungf = "flydung",
ssdungt = "flydung",
superfutter = "superfeed"
};
The problem is... well let me quote MSDN (source):
You cannot declare a field, a property, an event, or the return type of a method as having an anonymous type
But they don't say why.
So the question remains: why you cannot declare a field and property as having an anonymous type? Why .NET creators stripped it from that option?
I am getting warning here from SO that my question appears subjective, but I think it is not at all - there need to be objective reason for that.
As for me, I don't see any obstacles for that but somehow it is not supported. As compiler can easily generate the type for field or property of class, in a same manner as it does for local variables.
The option for me was to use dynamic type but unfortunately Mono engine I am using is stripped from that.
Also the option for me is to use object type and using later reflection to find these fields:
private static readonly object MAPPING = new
{
ssdungf = "flydung",
ssdungt = "flydung",
superfutter = "superfeed"
};
But using reflection is this situation is dirty I would say.
I tried to find answer, but I really didn't find any. Here are some SO answers to similar questions, but they don't answer why:
Can a class property/field be of anonymous type in C# 4.0?
Declaring a LIST variable of an anonymous type in C#
How do you declare a Func with an anonymous return type?
Why you cannot declare a field and property as having an anonymous type?
Because C# is statically typed, so any memory location has to be given a type, and declaration does so. With locals we can infer from context if its initialised at the same time as declaration with var but that is a shorthand for a type that is usable even when the type hasn't got a name.
What would a field with an anonymous type, that is to say a statically-bound but indescribable type, mean?
dynamic would indeed be the closest analogy to the code you are porting, but since that isn't available to you, you might consider using an IDictionary<string, object> (which incidentally is how ExpandoObject, which is often used with dynamic to have objects that behave more like javascrpt objects, works behind the scenes). This would be slower and less type-safe than if you created a class for the object needed, but can work.
The problem on an anoynmous property is: how do you get/set it?
Suppose it would work:
class MyClass
{
public MyField = new { TheValue = "Hello World" };
}
Now in your consuming code you´d write code to read the code:
MyClass m = new MyClass();
m.MyField.TheValue = "newValue";
How was this different from having a type for MyField? All you´d get is that you can omit two or three lines of code whilst gaining nothing. But I think you might produce many problems as no-one knows what he can assign to/expect from that member.
Furthermore you can´t do much with an anonymous object, basically you can just set it and read it. There are no methods (except Equalsand GetHashCode inherited from object) that you can call so the opportunities are quite low.
Last but not least an anonymous object is usually used as temporaryily, for example within a Select-statement. When you use it you say: this type is going to be used only within the current specific scope and can be ignored by the entire world as internal implementation-detail. Creating a property of an anonymous type will expose such a detail to the outside. Of course you could argue that the designers could at least allow them for private members, but I guess doing so would bypass the complete concept of accessability for nothing.
Currently I am doing something along the lines of:
public class UselessClass
{
public string x;
public int y;
}
I only ever use this class once in a function...
Dictionary<string, UselessClass> dict;
I'd like to be able to edit the values of the UselessClass, so I believe a Tuple isn't sufficient as they are read-only once created. I'd also like to have the named variables x and y to do things like:
dict["hello"].y++;
Can I do this without having to have this UselessClass sitting around the code when really it's only ever used once for a function? Some sort of anonymous class with named variables?
To add more details:
This is purely used in an algorithmic function where I want to adjoin a string with certain variables, namely another string x and an integer representing a distance
The best way I can think of adding properties to an already existing class like string is by using a dictionary.
Rather than doing:
Dictionary<string, string> names;
Dictionary<string, int> distances;
which seems like a waste of memory, I'd rather get both names and distances in the same structure.
But the structure itself is meaningless on its own, it's only used in the algorithm to perform a calculation.
No - anonymous types are immutable. If you want a mutable type use a class (not a struct). Using dynamic and ExpandoObject would be one alternative but you lose design-time type safety.
If you give some more context as how they are used there may be other alternatives.
To provide a similar solution as terrybozzio, albeit a less hackish one (using a single-element array isn’t exactly that nice), you could also use a wrapper that makes a type mutable:
class Mutable<T>
{
public Mutable(T value)
{
Value = value;
}
public T Value { get; set; }
}
You could then even use this for anonymous types:
var x = new {
Foo = "Bar",
Baz = new Mutable<int>(2)
};
Console.WriteLine(x.Baz.Value); // 2
x.Baz.Value++;
Console.WriteLine(x.Baz.Value); // 3
But as I said in a comment above, you can’t really use an anonymous type if you need to reference the type in the dictionary declaration. You could use a tuple, but overall, you gain a lot more flexibility if you just introduce a custom type. For example if you decide that you need another value in there (for whatever reason), then you can simply add it without everything breaking. If you on the other hand use a tuple or something similar, you would have to update every single use of it.
One possibility is like you said using Tuple but since their elements cannot be changed you can do a little "hack" if you wanna call it is to declare an Tuple<int[],string[]> so when you add an item to the dictionary you instantiate the tuple but with only 1 element in each array which can be manipulated:
Dictionary<string,Tuple<int[],string[]>> test = new Dictionary<string, Tuple<int[],string[]>>();
//here i add a new dict entry and to the int[] i assign the value 5.
test.Add("test1", new Tuple<int[], string[]>(new int[1]{5}, new string[1]));
test["test1"].Item1[0]++;
test["test1"].Item1[0]++;
//here the int will be 7.
Although i would go with the UselessClass...
I'm trying to write a generic method that will return specific markup when passed an enum. Below is the method which has been reduced to the minimum required code for this question.
public static string GetMarkup(Type enumType)
{
StringBuilder builder = new StringBuilder();
foreach (var val in Enum.GetValues(enumType))
{
builder.Append(val.ToString());
}
return builder.ToString();
}
The method is called like this where CopyType is an enum:
GetDropDownListHtml(typeof(CopyType))
The goal is to be able to call ToString() extension methods I've written for the enums I'll pass into this method. The problem is that to make the method generic, I need to use var to declare my variable in the foreach declaration, but that boxes it. Instead of an enum of CopyType, I have an object that is the boxed CopyType.
In response, I've tried many thinks like this, but to no avail:
((typeof(enumType))val.ToString()
Any ideas?
There's no way to use extension methods to do this to a specific enum. You either need to extend your extension method to support all Enum types, add an is statement in there which you can use to only cast it when necessary, or write a special overload to this function which you call just for this type of enum. This has to do with how extension methods are actually implemented.
The compiler turns an extension method into its static form: myCopyType.ToString() becomes CopyType.ToString(myCopyType) when compiled. But with your scenario (or even with generics) the compiler can't tell what type to use, because the type isn't determined until runtime.
This leaves the three choices above.
In my own code, I went with the first option, based on the code here. You'll be able to call .GetLabel() on any Enum type, and you can put your special labels on this one specifically.
Additionally, you'll need to use foreach (Enum val in ... instead, so as to make sure the compiler knows it's an Enum.
I have created a generic type to act as a pointer so that I can pass by reference. (Perhaps there is a much more simple way of doing this but I want to stress that I am doing this to learn more about generics and passing by reference, not the most efficient way of completing the task, if that makes sense.)
Here is the code I wrote for the generic type
class GenericPointer<T> {
public T item;
public void setItem(T i){ item = i; }
public T getItem(){ return item; }
}
In my program I have created an instance of this type called 'intPointer'. The value 143 is arbitrary.
GenericPointer<int> intPointer = new GenericPointer<int>();
intPointer.setItem(143);
Console.WriteLine(intPointer.getItem());
The above code runs properly, setting and returning the value 143.
I now want to pass this 'intPointer' to a method that increments it and then prints the value again.
So I wrote a method called addone()
public void addone(int i) { i ++; }
Now I want to make the following calls (remembering that I already set the value to 143):
Console.WriteLine(intPointer.getItem());
addone(intPointer);
Console.WriteLine(intPointer.getItem());
What I was expecting to see was 143 then 144 however I get the following errors:
The best overloaded method match for 'Notes.Program.addone(int)' has some invalid arguments
and:
cannot convert from 'Notes.GenericPointer<int>' to 'int'
Any help would be greatly appreciated!
I'll begin by correcting some of your terminology: you're not using pointers. C# does support pointers, but using the unsafe keyword, and they are real pointers (as in, integer memory addresses you can directly manipulate). The code you written is just an example of a boxed object.
.NET supports boxing already, by casting to Object; however it isn't recommended nor needed because the ref keyword solves the problem you're trying to "fix".
Use the ref keyword to describe a value-type parameter that should be passed by-reference instead of by-value. All other semantics remain the same, like so:
void Foo() {
int x = 123;
Bar(ref x);
Console.Write( x ); // prints "124".
}
void Bar(ref int x) {
x++;
}
I have a few other notes:
C# and .NET conventions dictate that all public members (methods, properties, fields, etc) should have TitleCase, not camelCase (i.e. ensure the first letter is capitalised).
Trivial getter and setter methods are discouraged, used Properties instead (though I note you cannot use ref arguments with properties).
You're getting your error because the type of intPointer is not int, but your class GenericPointer<int>.
While GenericPointer is wrapping an int, it is not actually an int so it cannot be treated as one. It has properties that are an int.
Imagine if GenericPointer wrapped a string. What would AddOne do to that.
You can act on the properties of the class but not treat the entire class as its generic type.
It would be possible to write an AddOne method that took a Generic Pointer argument and then inspected it for intyness and then added one to the internal item if it was an int. I am sure that is not a good idea.
What are you really trying to achieve with this GenericPointer?
If you want parameters to be reference if they are a value type (string, int, bool, etc.) then make your parameter like this:
public void addone(ref int i)
{
i++;
}
Then call the method like so:
addone(ref variableInt);
You can also look at this in order to see how to make your classes work as a specific type.
Id' like to create a list of data that will be passed from method to method, however I can't use a struct because the data that will be contained in this list will vary depending on the input.
For example
if (x == 1) {
a = 1
b = true
c = 42
d = "hello"
}
if (x == 2) {
a = 2
b = 'g'
c = "sup"
}
I believe my options are thus:
Create an array or List of strings, and cast the data back to what it originally was from strings. This is messy and could lead to bugs of uninterpretable input, though wouldn't be so bad since it'd all be detected at runtime.
Create a struct for each possibility - Is this even good practice?
Somehow use generics. From what I know, while generics are type-safe yet not type-strict, they must be cast to types before being used. Eg if I wanted a List of items here, I'd need to cast them to strings much like would happen with solution 1, making this useless.
My question then, is which of these options is the best? Or is there an alternate option using some sort of generic type I don't know about? The number of possible variables in each case may change, as with their types. I'd like to be able to return a single List or Array to the calling method, so that it may appropriately deal with the result. It will know how to deal with each group of data based on the value of a, as it will be the 'action choice' identifier. I'm also aware that casting them to objects and back each time is very intensive so I'd rather avoid that.
This is probably pretty simple but it has me stumped...
Since you don't know before hand what the list will contain, it looks like a good case for using an ArrayList.
If you want to get back to the values using a key, consider using a Hashtable.
The general principal in .NET is that every type can be cast to System.Object (although it may involve boxing). You can use a method like
void Foo(params object[] parameters) { ... }
Or use the System.Collections.ArrayList class.
The 'problem' is that when you want to use such a value, you will need code like:
if (parameters[i] is string)
{
string s = (string) parameters[i];
...
}
Sorry, this is not a code related answer: there may be a faulty design hidden behind such a construct. Make sure you know what you are doing, otherwise things might fire back.
If not knowing the type of the fields you use beforehand really is required, this calls for an approach that saves the data with their type, like
struct foo {
private object _value;
private string _type;
foo(string myType, object myValue) {
_value = myValue;
_type = myType;
}
}
and then using Generics to handle the business logic.
Basically you need a list typed to Object, and then yes, you're in a mode of casting back.
My question is, structurally, how will you know what indexes are of which type? This sounds like a painful solution at best.
If you really need to store differing types in the list, perhaps try a struct which contains a member of each type, as well as a flag indicating which data type is represented. Then use a generic collection for that struct. Something like (off the top of my head)
struct FooType
{
public string StringValue;
public bool BoolValue;
public int IntValue;
public char CharValue;
public string DataType;
// You'd probably want constructors too
}
Then the generic list:
var values = new List<FooType>();
Now you can add and remove entries in the list using that type, which would then indicate what the core data really is.
I still don't like the answer; it sounds like your design may be trying to do too much and there may be refactoring opportunities, but since I don't see much more of your code or intent, all I can do is answer what you've asked. :)
You could represent the data items using a Dictionary/Hashtable and then add these dictionaries to a List.
You could also add extra type information into the dictionary value if needed.