[Mono-list] *Calendar implementation

[Miguel de Icaza]

> > 	1. Use the registry calls from .NET and document as part of
> > 	   the class libraries (and document them in a new file here:
> > 	   mcs/class/docs/registry-keys with the information)
> > 
> > 	2. Abstract the call into a call that we can later abstract and
> > 	   adapt to the particular options of fetching this information.
> > 
> > I like the later, but it requires a couple of extra calls. 
> 
> The second approach isn't good, because we introduce a registry wrapper,
> just another class to understand and to maintain. I think we document
> the shortcoming and add the registry calls, when a registry exists. We
> should do some real architectural work here. I would even tend to say,
> that the registry is not one of Microsoft greatest achievements in
> software design. Let's try to do it a little better.

I like your plan.  But since Mono will run both on Linux and Windows, in
the Windows world it makes sense to fetch the configuration information
(if any) from the Registry (if needed) and on Linux systems we might
have to load the defaults from a different place or define our own.

That is why I suggested that this kind of thing be abstracted.  Sure, it
adds another layer to be understood in this particular case, but it
would be again an internal interface.  It does not even need to be fully
generic, we can compile different "backends" in the assembly depending
on the OS.  So the Unix version can live in the Unix directory, and the
Windows version in the Windows directory.  Depending on the compilation
we pick one of those files. 

> Before that I've to do NUNIT tests, it's easy to get calendar
> implementations wrong. (I've done some tests outside the Mono class
> structure but not inside.)

Nick will correct me if I am wrong, but I believe that getting the tests
on NUnit right now might be tricky, as the corlib tests will very likely
fail with .NET, you would need to run them with Mono directly (this is
because many of our tests in corlib are testing details of the
internalcall interface).

For now, writing standalone tests in NUnit should be enough if you only
have the .NET framework and not the Mono runtime deployed/runing. 

Miguel