Properties C# 2.0 - Not Elegant Enough !!!

Prior to .NET 2.0, there wasn't the facility in C# to opt the visibility level for the get and set property or indexers. And i take my comment in my previous post that C# does not provide the facility of having different visibility levels for the get and set accessors. While that is partly correct, it is no more in C# 2.0.

And obviously it isn't in the easy and elegant way. Take a look at this code snippet:-

public bool LogToStdError
{
get
{
return _log2StdError;
}
protected set
{
_log2StdError = value;
}
}
I do not have to explain the code except there are some restrictions while having different visibility levels for the get/set accessors of a property.

1. You can provide an explicit visibility either for get or set. Hence the following code will throw an error:-

public bool LogToStdError
{
protected get
{
return _log2StdError;
}
protected set
{
_log2StdError = value;
}
}

2. The visibility thus explicitly specified must be a subset [restrictive than] of the property declaration.
For example, if the property declaration is protected, then the get/set accessor cannot be like say public. So the following code throws an error:-


protected bool LogToStdError
{
get
{
return _log2StdError;
}
public set
{
_log2StdError = value;
}
}

I feel that these restrictions are stupid, and this resulted because of the syntax. I just thought of some ideas for a bit elegant syntax for the property definition.

1. The get and set accessors individually have to specify the visibility level.

bool LogToStdError
{
public get
{
return _log2StdError;
}
property set
{
_log2StdError = value;
}
}

2. The property declaration syntax must not bear any visibility level unless the associated get/set accessors do not bear any. For example, in the property definition below, the get/set accessors are public:-

public bool LogToStdError
{
get
{
return _log2StdError;
}
set
{
_log2StdError = value;
}
}

and as per this property definition, the get/set accessors are protected:-

protected bool LogToStdError
{
get
{
return _log2StdError;
}
set
{
_log2StdError = value;
}
}

3. If there are visibility levels specified neither in the property definition nor in the accessors, then the default visibility level as specified for C# [I guess internal] will be applied for the property accessors. Hence the get/set accessors are internal for the following property:-

bool LogToStdError
{
get
{
return _log2StdError;
}
set
{
_log2StdError = value;
}
}

Singularity - Safety & Speed !!!

I read about this interesting thing somewhere in MSDN.

There are two types of programming or programming languages. The good old C/C++ kind called the unsafe programming languages, and the other is the safe programming type which we realised very much after advent of Java/C#. And there has always been debate about safety and speed. And neither of the two has won.

So Microsoft is doing a research on a new operating system called Singularity which is written in a safe programming language [C#]. Although there are parts in the OS, especially the kernel, that uses unsafe code, it stills uses the safe C#. So in the Singularity environment, every program that runs is safe. And the environment as such is reinventing from the hardware layers up and above.

Any process in singularity will not be as huge as its counterpart in the unsafe world. It will start with very minimal image and bring up things as when required. But also there was some thing that i read but could not understand exactly. It said that Singularity processes are closed - dynamic loading of code is not allowed after the process starts executing.

Whatever, the environment is .NET as whole which means that .NET is not just libraries on the disk instead it is into the kernel. Microsoft is doing the research to prove that there is no compromise between speed and safety with this safe programming environment, and also help programmers stopping worrying about the choice of speed or safety.