Learning Type Access Modifiers Basics !!!

When I started developing my module, I had an interface IParamCountBasedAlgo declared as a nested type in a class AlgorithmOneExecutor, declared as follows:-

namespace DataStructuresAndAlgo
{
partial class AlgorithmOneExecutor
{
private interface IParamCountBasedAlgo
{
void Validate();
void Execute();
}
}
}

There were other concrete nested types inside AlgorithmOneExecutor that implemented IParamCountBasedAlgo. But later, other types nested in other than AlgorithmOneExecutor emerged that required to implement IParamCountBasedAlgo. So I moved IParamCountBasedAlgo from a nested type to a direct type under the namespace DataStructuresAndAlgo, as declared below:-

namespace DataStructuresAndAlgo
{
private interface IParamCountBasedAlgo
{
void Validate();
void Execute();
}
}
And the compiler spat an error "Namespace elements cannot be explicitly declared as private, protected, or protected internal". Then a simple research gave me an insight that types directly under namespace can be declared either public or internal only, and the default is internal. Seems reasonable cuz if declared private, it gives an ambiguous look that it cannot accessed or created and protected seems rather very unrelated. Hence either public or internal only.

A subtle point to note is that not all access modifiers are applicable for all types and at all declaration levels. To learn the basics of type access modifiers, visit http://msdn2.microsoft.com/en-us/library/ms173121.aspx

where enum does not work !!!

I was writing a generic method with enum as the Constraint, and the compiler spat a few errors that did not directly convey me that enums cannot used as generic constraints. And I learnt the following from my investigation:-

This is an excerpt from the C# Language Specification. Enums are value types and there is no way that you can specify the System.ValueType as a constraint, as per the specification. But if you wish to specify a non-reference type as a [primary] constraint, struct can be used.

private void Method where T : struct

That does not guarantee that our generic method will not accept other value types, besides enum, for which we do not support our functionality.

During the course of investigation, I was extremely surprised to know that the numeric types like int, float etc in C# are struct. It is not far from the fact that they are value types, but it was interesting to know that they are declared as


public struct Int32 : IComparable, IFormattable, IConvertible, IComparable, IEquatable

Similar thing for other numeric types. Whereas an enum [System.Enum], though a value type, is declared as an abstract class that derives from System.ValueTypes unlike the int or float. The end result is that enums are value types but i wonder the way they are declared.

Anyway, the question still remains unresolved - why enums cannot be used as constraints, andjust the specification saying that enums cannot be used as constraints is unsatisfactory.

I am not sure if there is any other way to resolve my situation.
Question open to cyber space !!!

P.S.
Refer section 25.7 through for the specification on Generic Type Constraints.

First Google Gadget(s) !!!

I did some cool stuff here with google. I wrote my first "Hello World" sort of google gadget. It claims no rewards but just was fun. Since I am a novice in html and javascript sort of things, this gadget is pretty simple.

Use the following URLs

http://vivekragunathan.googlepages.com/Pirate.XML
http://VivekRagunathan.GooglePages.com/Clock.XML


to enjoy the gadgets.

Overloading......A Matter Of Taste !!!

This was a pretty interesting discussion about method overloading in the managed world. As the discussion says that the overloading is a matter of taste. It seems that the method overloading in the managed world, indeed, is a matter of taste. Sad BUT True !!! But on the contrary, it must have been a [strict] rule. Overloading might be exhibited differently by each language in the unmanaged world. But as far as .NET goes, it must have been made a standard specification. Pardon me, if there is one.

As it was pointed out in the discussion, how do we define the behaviour in the case where we derive classes across assemblies developed in another .NET language ?

As far traditional C++ goes, the overloaded method resolution starts from the derived but does not have strict type checking eg. for numeric types]. And the point to note is that only the method in the derived class with the exact prototype as the base is considered the overload. Ofcourse, C++ is not as much type safe as C#. This is taken care in C# by the override keyword which allows only the exact prototypes to be involved in overloading. And at times explicit casting is required unlike in C++.

But in the case of C#, the first principle observed in overloading is to avoid it. Pretty confusing, huh? Take a look at the example below:-


namespace Samples.MyConsole
{
class Parent
{
public void Foo()
{
Console.WriteLine("Parent.Foo");
}
}

class Child : Parent
{
public void Bar()
{
Console.WriteLine("Child.Bar");
}
}

class Base
{
public virtual void XYZ(Child c)
{
c.Foo();
c.Bar();
}
}

class Derived : Base
{
public virtual void XYZ(Parent p)
{
p.Foo();
}

public override void XYZ(Child c)
{
base.XYZ(c);
}
}

class User
{
public static void SomeMethod()
{
Child c = new Child();
Parent p = c as Parent;

Derived d = new Derived();
Base b = d as Base;

Console.WriteLine("Playing with Derived");
d.XYZ(c);
d.XYZ(p);

Console.WriteLine("\nPlaying with Base");
b.XYZ(c);
b.XYZ(p as Child);
}
}
}

Here is the output at the console:-

Playing with Derived
Parent.Foo
Parent.Foo

Playing with Base
Parent.Foo
Child.Bar
Parent.Foo
Child.Bar

You would have guessed the surprise that you are about to experience. Yes, d.XYZ(c) calls the Derived.XYZ(Parent p), and not the Derived.XYZ(Child c) which is a better match. It does if it had been defined as public new void XYZ(Child c). But same is not the case with C++. It gives us no suprise.

And as far as C++/CLI is concerned, it behaves as traditional C++.

So the intriguing bitter part is that the overloading in the managed world is not a thing at the CLR level nor does it seem to be something concerned with the specification. It seems to be a matter of taste.

Follow the trail.......Join the Concurrency Revolution !!!

I could not stop writing this post after I read this article by Herb Sutter. The article is just a casual technical discussion but very encouraging that a person requires at the right time - the time when he is a student. Even after several years after my college, I have been trying to keep myself a student and I got a right encouragement to join the Concurrency revolution. Thanks to Herb Sutter.
As Albert Einstein, Robert Goddard, and Wernher von Braun walked the trail of Galileo and Newton , I will to walk the trail of some of the contemporary people like Sutter, Stroustoup, Don Box, Richter and others.

The New Looking Post !!!

I am very much fond of tools, updates and stuff. So I keep updating my softwares and hear/learn about new tools etc. I am excited about the new spaces - Live Spaces. Looks much better than before. I thought I would write something about the new spaces. Please 'spaces guys', make the arranging the boxes on the home page a bit easier and intelligent. That is a feature request. Otherwise the default skin/theme is cool and professional. Old themes are still old and not much appealing. Anyway, i write the post just to say i love it.

And talking about tools and softwares, i heard this news about Microsoft acquiring the SysInternals tools. And probably, Microsoft might be shipping the tools like Debug View, Process Explorer, RegMon etc with the Windows SDK. Me not sure of that, better read what Tom Archer said.