It is said here
http://msdn.microsoft.com/en-us/library/fa13yay7%28v=VS.90%29.aspx (see also http://msdn.microsoft.com/en-us/library/s4wcexbc%28VS.90%29.aspx)
Use this option if you want to define
or create your own System namespace
and objects.
But how ? Where can I find some examples ?
Update: of course my question is not about how to create a namespace or a class but about an example of custom system architecture (an UML schema and source code).
For example could this be used to port .NET on other processors like iphone ? Does Mono use this ?
Is there some smallest possible example instead of whole commercial clr to learn from ?
How? Just write the code. Make a namespace called System that contains a class called Object and a class called String, and the compiler will pick that up and use it instead of the framework class library version. That's how the framework team does it. All you have to do is replicate all their work yourself and you too can be in the framework class library providing business.
Note that in many cases the compiler has been designed to expect that the types in the System namespace are exactly as they are documented to be. I've had bug reports in the past - extremely confusing bug reports! - where someone has redefined, say, System.Collections.Generic.IEnumerator<T> to have different properties and methods than the "real" one, and then they're all surprised and vexed that the compiler generates crazy broken code for a "foreach" loop. If redefining the basic interfaces is the sort of thing you want to do, consider writing your own C# compiler too. Ours is by design not robust in that scenario.
I don't know why you want to do that but you just have to create a custom "System" assembly (like a standard library) and use it as a reference in your other project with /nostdlib+ set.
namespace System
{
public sealed class String : IComparable, ICloneable, IConvertible, IComparable<string>, IEnumerable<char>, IEnumerable, IEquatable<string>
{
...
}
}
Related
Let's say I have the simplest of interfaces for all components in my program.
public interface IComponent
{
}
I know that every single component to be written for the project has to implement this interface, and I know that all of these components will be saved to disk using C#'s BinaryFormatter. That means that every component has to be decorated with the [Serializable] attribute. Is there a way to enforce the addition of this attribute now?
I say "now" because I can find various SO questions that tell me this isn't possible - but all of the questions I can find are from 2008. Has anything in the C# spec changed since then? Or do I have to use one of the workarounds described in the old answers?
You could write unit tests that picks ups all implementation of IComponent from your library using reflection and checks if they have the Serializable attribute on them. I don't belive anything new was introduced in .NET since 2008 that could make that check compile time specific, sorry.
This question is for interest sake. I'm working with a third-party library and came across the following documentation on a CMS.Security.Dummy class:
DO NOT DELETE THIS CLASS - This class prevents the compiler from
dropping entire namespace under .NET 4.0.
Does anybody know, or can anybody speculate why .NET 4 would drop the namespace if the dummy class were removed?
Because .NET 4 is explicitly named in the source code comment, I assume previous C# versions exhibit behaviour that do not require this dummy class. That's purely speculative though.
Screen shot
Decompiled Source Code
#region Assembly CMS.SettingsProvider.dll, v4.0.30319
// ...\solution\wwwroot\Bin\CMS.SettingsProvider.dll
#endregion
using System;
namespace CMS.Security
{
// Summary:
// DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
// entire namespace under .NET 4.0.
public class Dummy
{
// Summary:
// DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
// entire namespace under .NET 4.0.
public Dummy();
}
}
A little-appreciated fact is that there is no such thing as a "namespace" from the point of view of the underlying CLR type system. Rather, it's just a convention that we say that a type that contains periods in its name is "a member of a namespace". Logically there is no difference at all between the legal code:
namespace N
{
class C {}
}
and the psuedo-code:
class N.C {}
C# forces you to pretend this pleasant fiction is reality, but it is just a fiction -- from the perspective of the CLR type system, of course. From the perspective of the C# compiler, of course namespaces are "real". They just don't correspond to anything in metadata other than a portion of the name of a type.
In short: if you make an assembly with an "empty" namespace then the "namespace" doesn't exist at all in the compiled binary. A "namespace" only comes into existence when there is a type in the library that has periods in its name.
Now, why you would care about ensuring that an "empty" namespace has some presence in the binary form, I have no idea.
I assume previous C# versions exhibit behaviour that do not require this dummy class
Nope. Every version of C# since 1.0 throws away empty namespaces.
Given that the namespace doesn't contain any members (without that class), I'm not sure there's even the concept of a namespace at that point... nor would I expect it to be useful anyway.
I've just tried to reproduce this with the C# 2 compiler, and I can't see any trace of an empty namespace within the IL.
The only semi-related issue I can think of is that when compiling a project in msbuild, indirect references are not always copied to the bin directory of the current app. If library B indirectly references library A and library C references B only, library A's output will not necessarily be copied to the bin folder when compiling library C. In the past, I've used a null field reference on a class to ensure that the dependency is explicit and the output is deployed properly. Maybe the original devs experienced something similar and this was their solution?
With C++, I can have one class definition in a header file, and have a multiple implementation files by including the header file.
With C#, it seems that there is no such header file, as one class should contain both definition/implementation.
I wonder if the number of lines can be very big, because one can't separate the class into multiple files. Am I correct? I mean, in some cases, one can't change the class design to have smaller classes. In this case, is there a way to solve this problem?
You can separate a class into multiple files using the partial keyword
public partial class ClassNameHere
{
}
It is possible to split the definition of a class or a struct, or an interface over two or more source files using the Partial keyword modifier Link to msdn with the partial class
Partial classes only give you so much. There is still no way, that i know of, to split your class definition from implementation, such that each exists in a separate file. So if you like to develop based on a need-to-know paradigm then you are sort of stuck. Basically there are three levels a developer can work at...
1) Owns all the code and has access to, and maintains all of it.
2) Wishes to use some useful base class(s) which may form part of a framework, or may just be a useful class with some virtual methods, etc, and wishes to extend, or re-implement some virtual base class methods of interest. Now the developer should not need to go and look at the code in the base class(s) in order to understand things at a functional level. If you understand the job of a function, it's input and output parameters, there is no need to go and scratch inside source code. If you think there's a bug, or an optimization is needed, then refer to the developer from 1) who owns and maintains the base code. Of course there's nothing saying that 1) and 2) cannot be associated with the same developer, in which case we have no problem. In fact, this is more than often the case i suspect. Nevertheless, it is still good practice to keep things well separated according to the level at which you are working.
3) A developer needs to use an already packaged / sealed object / component dll, which exposes the relevant interfaces.
Within the context of c#, 1) and 3) have no problems. With 2) i believe there is no way to get round this (unless you change from exposing virtual base methods to exposing interface methods which can be reimplemented in a component owning the would-be base class). If i want to have a look at a class definition to browse over the methods, scaffolding functions, etc, i have to look at a whole lot of source code as well, which just gets in the way of what i am trying to focus on.
Of course if there is class definition documentation external to how we normally do it ( in headers and source files), then i must admit, that within the context of 2), there is not reason to ever look into a class definition file to gain functional knowledge.
So maybe clever Tom's came up with c#, decided to mix class definition with implementation in an attempt to encourage developers to have external documents for their class definitions, and interfaces, which in most IT companies is severely lacking.
Use a partial class as #sparks suggests, or, split into several classes. It's a good rule of thumb that, if you can't fit a class onto a couple of pages, it's complicated enough to need breaking apart.
Having mostly worked with C#, I tend to think in terms of C# features which aren't available in Java. After working extensively with Java over the last year, I've started to discover Java features that I wish were in C#. Below is a list of the ones that I'm aware of. Can anyone think of other Java language features which a person with a C# background may not realize exists?
The articles http://www.25hoursaday.com/CsharpVsJava.html and http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp give a very extensive list of differences between Java and C#, but I wonder whether I missed anything in the (very) long articles. I can also think of one feature (covariant return type) which I didn't see mentioned in either article.
Please limit answers to language or core library features which can't be effectively implemented by your own custom code or third party libraries.
Covariant return type - a method can be overridden by a method which returns a more specific type. Useful when implementing an interface or extending a class and you want an overriding method to return a type more specific to your class. This can be simulated using explicit interface implementation in C#, but there's no simple equivalent when overriding class methods.
Enums are classes - an enum is a full class in java, rather than a wrapper around a primitive like in .Net. Java allows you to define fields and methods on an enum.
Anonymous inner classes - define an anonymous class which implements a method. Although most of the use cases for this in Java are covered by delegates in .Net, there are some cases in which you really need to pass multiple callbacks as a group. It would be nice to have the choice of using an anonymous inner class.
Checked exceptions - I can see how this is useful in the context of common designs used with Java applications, but my experience with .Net has put me in a habit of using exceptions only for unrecoverable conditions. I.E. exceptions indicate a bug in the application and are only caught for the purpose of logging. I haven't quite come around to the idea of using exceptions for normal program flow.
strictfp - Ensures strict floating point arithmetic. I'm not sure what kind of applications would find this useful.
fields in interfaces - It's possible to declare fields in interfaces. I've never used this.
static imports - Allows one to use the static methods of a class without qualifying it with the class name. I just realized today that this feature exists. It sounds like a nice convenience.
Java has packages that reflect a hierarchy and filesystem layout, while in C# the assemblies are irrespective of the namespace hierarchy.
Octal literals! :D
int x = 0245; System.out.println(x);
165 is outputted. Fun :)
Java's generics allow type wildcards. For example, <T extends Object & Comparable<? super T>> T Collections.max(Collection<? extends T>) { ... } is not expressable in C#.
In C#, you cannot have a return statement in a finally block.
I don't know if you want this in your language, but I guess Type Erasure can be seen as a feature to some.
what could be a possible use of declaring types within a namespace but not in a class.
For ex:
namespace Test
{
public delegate void Ispossible();
}
This is valid & does not generate any compilation errors but i can't think of why we would declare it this way as opposed to inside a class.
A namespace is a high-level unit of organization within .NET.
Declaring types within classes is typically frowned upon (but, as with all things, it's not a 100% rule) because it can make the types more tightly coupled and more difficult to find.
VB.NET Modules are somewhat of an exception (edit: they're really more of a compiler trick/syntactical-sugar), but normally everything in the .NET ecosystem is contained in a namespace.
Your example lends itself to reuse; if it were within a class then it would imply that delegate should only be used by that class and would likely lead to duplicate delegates needlessly being introduced.
Update: When working with only a handful of types namespaces don't seem of much use, but without them a project of any size would be an organizational catastrophe. Imagine the .NET framework without namespaces, one (probably long outdated) count puts the framework at 3500 Types.
Namespaces are like folders or drawers for documents; a few loose papers are easy to manage but if you have many pages then finding the one you need becomes painful.
Give the documentation a read, it's short and not terribly complicated (neither are namespaces) but has a couple decent points MSDN - Namespace (c#)
If it is a multi purpose delegate such as Func<TResult>, EventHandler which is not related to a particular class then you should declare it in the namespace directly.
Your phrasing ("what could be a possible use of declaring types within a namespace but not in a class."), indicates that you draw a distinction betweens "types" and "classes". There is none. A class is a type.
So, under what conditions would you want to declare a class directly in a namespace (i.e, the way it is most commonly done) ? These same reasons apply to other kinds of types.
Both namespaces and classes can be used to organize information in hierarchy. However namespaces allow to distribute definition across dll boundaries, but classes do not. Also classes require to put class name before type name, but namespaces allow to use keyword "using".
So if you want to define delegates in one namespace in different dlls, you use namespaces.
If you want to force people to prefix type name with any other name without being able to rely on namespace context then you use classes.