Comments for Togaroga

Comment on Know your framework by Yogesh Kamble

Yogesh Kamble — Thu, 14 Apr 2011 13:45:43 +0000

Nice Article …….

Comment on You don’t always need a lambda expression by Bones

Bones — Wed, 13 Apr 2011 11:27:01 +0000

You’ve hit the ball out the park! Icrndeible!

Comment on Two structural additions to C# by Micheal

Micheal — Wed, 13 Apr 2011 05:07:09 +0000

Stands back from the kybeorad in amazement! Thanks!

Comment on Choosy developers choose interfaces by Choosy developers choose interfaces

Choosy developers choose interfaces — Thu, 09 Dec 2010 07:37:37 +0000

[...] unnecessary restrictions on the caller of the method that requires them to pass too specific of… [full post] Andrew Andrew Hare's Blog codebest-practicec#interfaces 0 0 0 [...]

Comment on Overload resolution puzzler by spender

spender — Wed, 24 Nov 2010 02:16:04 +0000

More interesting is the resolution of:

Parent child = new Child();
child.Foo("test");

You need to cover this for a comprehensive foray into the issue.

Comment on Overload resolution puzzler by Pepe

Pepe — Mon, 08 Nov 2010 19:22:28 +0000

I thought the obvious thing would indeed be that the program would print "Child.Foo". The resolver can't try to determine what the "best" method is based on parameter type, after all, what if the parent method was "Parent.Foo(String a, Object b)" and the child method was "Child.Foo(Object a, String b)"? There would be no way to ever determine that one method matched a call better than the other simply by parameter types.

So instead, for a given method call, the resolver instead looks through the class hierachy, starting with the object's class then UP-ward, and uses the first method that matches (even if some ancestor method might match "better"). So child methods can indeed hide parent methods (I think the compiler will issue a warning when compiling the Child class). A caller could type cast the child object to Parent when calling Foo in order to call Parent.Foo rather than Child.Foo.

Comment on Overload resolution puzzler by o. nate

o. nate — Mon, 08 Nov 2010 18:14:32 +0000

This behavior may be by design, but I’d argue it’s a bad design. For one thing, if you’re worried that a base class might be trying to maliciously change the behavior of your program, then you have no right to be using that base class in the first place. If a base class wanted to do something malicious, there are a lot of easier ways it could go about that without relying on this particular behavior – it could simply change some of the base class behavior that we do rely on, since presumably we are deriving from this base class for a reason. So I think that’s a false argument. The more realistic argument is that the base class could accidentally change some behavior of the derived class. That is indeed a possible problem. However, there is another possible problem which is just as bad – ie., that the derived class could accidentally change some behavior of the base class. And the decision to implement overloading in this way actually makes it much more likely that just this situation could occur. By implementing this in a counter-intuitive way, the language designers increase the probability that the derived class might override some base-class behavior that it meant to preserve. So I’d say that in the best case this is a net neutral – but since it is more counter-intuitive, I’d call it a net negative.

Comment on Overload resolution puzzler by Andrew

Andrew — Mon, 08 Nov 2010 17:14:32 +0000

@Huh - Yes, you can overload any method on a base class this way (not override - overriding a method is different).

Comment on Overload resolution puzzler by Huh

Huh — Mon, 08 Nov 2010 16:51:32 +0000

So this means that i can override ANY method, just by using object as parameter(s) and then casting it to whatever I’d like inside the function?

Comment on Two structural additions to C# by Andrew

Andrew — Wed, 09 Jun 2010 20:22:54 +0000

That’s an excellent question! This concept would hopefully support all types, not just anonymous types. That means that any type that is structurally equivalent would implicitly implement the interface. This would be helpful with working with 3rd party types that don’t implement interfaces that you wish they did. As for anonymous types, they would never be able to implicitly implement any interface that had methods since anonymous types cannot be declared with methods.