I have a function that takes in a bool, shown below:
public void LoadEndPoints(bool mock)
{
}
I can call this via LoadEndpoints(true) or LoadEndpoints(false), but this can be a bit hard to understand, as you need to know what true/false represents. Is there a way to pass the parameter name and value to a function such as LoadEndPoints(mock = true)?
Yes!
You can specify the parameter names like this:
myObject.LoadEndPoints(mock: true);
Further Reading
Named and Optional Arguments (C# Programming Guide)
Another way to improve readability of your code would be to use an enum, like this:
public enum LoadOption
{
Normal,
Mock
}
public void LoadEndPoints(LoadOption option)
{
...
}
Then the call would look a bit like this:
myObject.LoadEndPoints(LoadOption.Mock);
You could use 'Named arguments', a C# 4.0 feature; and thus call: myObject.LoadEndPoints(mock : true);
If readability is indeed your prime concern, you could even expose two explicit methods, and internally reuse the logic - something similar to:
public void LoadEndPointsWithoutMock()
{
LoadEndPoints(false);
}
public void LoadEndPointsByMocking()
{
LoadEndPoints(true);
}
private void LoadEndPoints(bool mock)
{
}
Also, I wouldn't say that LoadEndPointsWithoutMock, etc. are great method names. Ideally, the names should have something to do with the domain.
You can use a KeyValuePair:
KeyValuePair kvp = new KeyValuePair(BoolType, BoolValue)
Yes, you can do it with the following syntax in c#:
myObject.LoadEndPoints(mock : true);
And in VB:
myObject.LoadEndPoints(mock := true)
Use named parameters. Have a look at this Named and Optional Arguments
Related
I am new to C# and still understanding the concept of delegates. What I know of delegates is that delegates define a function signature and functions with the same signature can be added to that delegate.
public class ss
{
public delegate void sampleDelegate();
public ss()
{
sampleDelegate s1 = new sampleDelegate(sampleMethod);
s1+= new sampleDelegate(sampleMethod2);
s1();
}
public static void sampleMethod()
{
}
public static void sampleMethod2()
{
}
}
In the above code I create a delegate and give it sampleMethod and sampleMethod2. When I call s1() it calls both sampleMethod() and sampleMethod2().
What if I want to only call one of those methods and that decision is to be made at runtime?
I may be missing something very small but delegates are really confusing to understand.
What if i want to only call one of those methods and that decision is to be made at runtime?
Then you don't combine them together, basically. For example:
// Names changed to be more conventional
SampleDelegate s1 = someCondition
? new SampleDelegate(SampleMethod)
: new SampleDelegate(SampleMethod2);
// This will call either SampleMethod or SampleMethod2, depending on condition
s1();
Note that normally I'd use a method group conversion, but you can't use method groups for the second and third operands of the conditional operator. You could use:
SampleDelegate s1;
if (condition) {
s1 = SampleMethod;
} else {
s2 = SampleMethod2;
}
... or
SampleDelegate s1 = someCondition
? new SampleDelegate(SampleMethod)
: SampleMethod2;
Neither of these looks particularly nice to me though.
Delegates are like pointers to a method. At run-time, there's nothing that differentiates calling a delegate or a method excluding that a method is a member of an object:
some.Method();
someDelegate();
The goal of delegates is creating a blackbox where you expect some code to put some behavior, and you simply rely on a method signature.
At the end of the day, they're like method interfaces:
// It must be a parameterless method which returns no value
public delegate void Action();
// vs
// It must be a class which implements a parameterless method "Do"
// which returns no value
public interface Action
{
void Do();
}
That is, a method can't be conditionally be switched with other, but you need to use regular control flow blocks like if or switch to take decisions about what to do.
In order to don't duplicate Jon Skeet's answer, I'll add another possible solution:
string text = "";
sampleDelegate s1 = () =>
{
if(!string.IsNullOrEmpty(text))
{
SampleMethod1();
}
else
{
SampleMethod2();
}
};
s1();
Check that, instead of creating two instances of sampleDelegate you can create one that handles the conditional logic to either call SampleMethod1 or SampleMethod2.
The whole () => { } thing is called anonymous delegate.
It can be also expressed as follows:
string text = "";
sampleDelegate s1 = delegate()
{
if(!string.IsNullOrEmpty(text))
{
SampleMethod1();
}
else
{
SampleMethod2();
}
};
But don't use above syntax... It comes from the old .NET days (.NET 1.0/1.1/2.0).
In summary, a delegate could or could not be provided as an actual class method, but you can combine class methods with anonymous delegates to meet your needs.
What if i want to only call one of those methods and that decision is
to be made at runtime? I may be missing something very small but
delegates are really confusing to understand.
Actually this is the reason to use delegates, but you're right when you say you're missing something.
Delegates are used to situations like the following one:
public void DoStuff(string text, Func<string, string> textFormatter = null)
{
Console.WriteLine(textFormatter != null ? textFormatter(text) : text);
}
You might call DoStuff either this way DoStuff("hello world") or DoStuff("hello world", text => $"<strong>{text}</strong>").
DoStuff method implementation doesn't know how to format the given text, and you provide an optional parameter to give a delegate as argument that will receive the whole text to format and it will return the formatted text.
Isn't this some way conditional after all? Based on the caller, DoStuff formats the text in a custom way. You can even provide a default format:
public void DoStuff(string text, Func<string, string> textFormatter = null)
{
// We'll give a default formatter if none is provided ;)
if(textFormatter == null)
textFormatter = text => $"<span>{text}</span>";
Console.WriteLine(textFormatter(text));
}
I have two Enumerators and a method that takes an enumerator. They are called ABC and DEF and the method is called TestMethod(Enum myEnum). Code is below:
public enum ABC
{
Zero,
One,
Two
};
public enum DEF
{
Zero,
One,
Two
};
public void TestEnum(Enum myEnum)
{
...
}
The function TestEnum takes any enumerator. How can I test which one of the two does the passed in parameter belong to? I could blindly start testing it out with try / catch casting but sheesh that's ugly. Any cleaner ways of doing this? Thank you in advance for any help.
How can I test which one of the two does the passed in parameter belong to?
You can just call GetType:
Type type = myEnum.GetType();
It's not clear what you want to do with it after that, mind you.
Alternatively:
if (myEnum is ABC)
{
}
else if (myEnum is DEF)
{
}
EDIT: If you're able to change the method signature and if your callers will know the type, then as per Jeppe's comment, you could use:
public void TestEnum<T>(T value) where T : struct
{
// Use typeof(T) here
}
You can't constrain T to be an enum type with normal C#... although there are hacky ways of writing code with such constraints applied via post-processing.
Mr. Skeet already nailed this but!
What about two methods.
public void TestEnum(ABC abcEnum) {
//do ABC stuff
}
public void TestEnum(DEF defEnum) {
//do DEF stuff
}
You get the branching you need but without having to worry about getting the if statement right. True it's only an if statement but what if you add enum GHI. Now there's some unaccounted for input for TestEnum to handle. Using overloaded methods you'd catch that while compiling (or even better, intellisense would catch you).
I've got somebody's F# library with a type in it:
module HisModule
type hisType {
a : float;
b : float;
c : float;
}
I'm using it in C#, and I would like to add a "ToString()" method to it, in order to facilitate debugging.
But the following doesn't seem to work:
public static class MyExtensions
{
public static string ToString(this HisModule.hisType h)
{
return String.Format("a={0},b={1},c={2}", h.a, h.b, h.c);
}
}
....
var h = new hisType();
Console.WriteLine(h.ToString()); // prints "HisModule+hisType"
Any ideas why not?
As others have pointed out, the ToString on object will always be a better match than your extension method. You should probably change the signature of your extension method; changing the name is probably the right way to go.
Moreover: you said that the purpose of this thing was to facilitate debugging. Overriding ToString might be the wrong thing to do there; ToString might be used for something other than debugging. I would be inclined to make my own specially-named method whose name clearly reflects the purpose of the method.
If you are creating a new type and want to have special display behaviour in the debugger, the easiest thing to do is to use the Debugger Display Attributes.
If you want to get really fancy to display a complex data structure in an interesting way, consider writing a Debugger Visualizer.
The answer to your question is "yes". Your sample does not succeed, however, because method resolution succeeds when it finds object.ToString(), so the compiler never looks for extension methods. Try it with a different name:
public static class MyExtensions
{
public static string Foo(this HisModule.hisType h)
{
return String.Format("a={0},b={1},c={2}", h.a, h.b, h.c);
}
}
....
var h = new hisType();
Console.WriteLine(h.Foo());
I think you can not do that, as ToString() is always there, in any object of CLR world.
Check out Eric Lippert answer.
You could create a wrapper type (with an implicit conversion) that overrides ToString.
class MyType {
private readonly hisType _hisType;
private MyType(hisType hisType) {
_hisType = hisType;
}
public static implicit operator MyType(hisType hisType) {
return new MyType(hisType);
}
public override string ToString() {
return String.Format("a={0},b={1},c={2}", _hisType.a, _hisType.b, _hisType.c);
}
}
hisType y;
MyType x = y;
Is there a way to invoke a generic function with a type known only at run time?
I'm trying to do something like:
static void bar()
{
object b = 6;
string c = foo<typeof(b)>();
}
static string foo<T>()
{
return typeof (T).Name;
}
Basically I want to decide on the type parameter only at run time, but the function I'm calling depends on the type parameter.
Also I know this can be done with reflections... but it's not the nicest solution to the problem...
I'm sort of looking for dynamic features in C#...
I'm writhing a bridge between two classes the first one is basically a big tree with different types of of objects (composite by interface) the other is a sort of a "super visitor".
the supper visitor accepts key-value dictioneries that map types to object it looks like:
dic.Add(object value)
and T is not necessarily the type of the value... a lot of times it isn't...
I know it's written poorly, but i can't fix it...
I can work around it, but only at runtime...
I already did it with reflections, but if there's a better way to do it without them i would be happy to learn...
Thank you
This is a bit of a hack but you can get dynamic to do the reflection work for you by something like,
class Program
{
static void Main(string[] args)
{
var b = 6;
var t = (dynamic)new T();
var n = t.Foo(b);
}
class T
{
public string Foo<T>(T a)
{
return typeof(T).Name;
}
}
}
Here the dynamic call will extract the type of b and use it as a type parameter for Foo().
You can use dynamic keyword if you're using .NET 4. In a word, the type of the variable will be resolved at run time so it is a super generic type ;) You can read a article here or read the MSDN documentation
Saly refelction is THE solution to the problem, whether it is nice or not is irrelevant here. It is the runtime designed mechanism to achieve exactly this. As there is no parameter or generics to use as input, this is the only way to do it - it is also senseless. As in: your example is bad. Because in the example the type is hardcoded.
If the method where b exists has b as generic parameter, the type is available for passing to foo. If not - reflection is THE way to go, albeit the syntax looks clumsy. Only one time, though.
This I believe is the only way:
var foo = typeof(Foo<>).MakeGenericType(typeof (bar));
You can set up a class which takes a type parameter at run time which can be used in the methods in that class.
public class GenericClass<T>()
{
ICommonInterface TheObject;
public GenericClass(T theObject)
{
TheObject = theObject;
}
public string GetName()
{
return TheObject.Name;
}
}
But this is only really useful if the Types being passed in share interfaces so have common properties between them. In your example it seems that relection is the answer as depending on the type you want to access specific properties.
I have seen multiple tutorials that show C# method creation with parentheses containing parameters or simple empty. I have also seen a C# method written with out parentheses.
public int Value {
get{ return _Value; }
set{ _Value = value; }
}
I haven't tested out that code but is this allowed? Is it considered bad form?
That is a Property and not a method. If you create a Method then it requires ().
As in Philip's answer, your example code is actually a Property,
But you perhaps have hit on something that many actually miss and that is that Properties are implemented using one or two methods. They get created for you by the compiler and contain the contents of each of the get and/or set blocks.
So, a property of:
public string Name {
get {
return "Fred";
}
}
Is a nicer way of writing:
public string GetName() {
return "Fred";
}
Parentheses are mandatory when declaring or invoking a method.
As others have said, what you've shown there is a property, which is implemented as one or two methods behind the scenes (one for each of the "getter" and "setter").
However, you will sometimes see method names without parentheses - these are called method groups and are used to construct instances of delegate types.
For example:
public void Foo(string x)
{
...
}
...
Action<string> action = Foo;
Here Action<string> is a delegate type representing a call with a single string parameter and a void return type. This assignment creates an instance of that delegate type which will call the Foo method when it's invoked, e.g.
action("Test");
will call Foo with an argument of "Test".
That is a property, not a method. A method requires parenthesis.
Bad form depends on context, there are a few design considerations to take into account when deciding to use a property or not.
MSDN has a nice list here: http://msdn.microsoft.com/en-us/library/ms229006.aspx