[Mono-list] difference between corlib.dll and System.dll and other questions

[Miguel de Icaza]

> I've implemented some classes missing in System.Globalization
> (*Calendar) as my first C# code.

Wow.  Excellent!  

> Classes from the System.Globalization namespace can be found in
> corlib.dll or System.dll. How can I decide, where to put the classes?
> Looking with ildasm.exe into mscorlib.dll? The *Calendar classes are not
> part of the ECMA all.xml, so it isn't obvious.

The main documentation entry point for a class in the documentation
browser that is part of .NET says which assembly the class belongs to
(It is under Requirements/Assembly in the text).

> (2) How to call a namespace for helper classes?
> 
> I've some helper classes in a seperate namespace. Can I call it 
> System.Globalization.CalendricalCalculations? I used the algorithms
> from the excellent book "Calendrical Calculations" by Nachum
> Dershowitz and Edward M. Rheingold.
> 

I would keep it on System.Globalization, and just make the helper
classes `internal'.  That means that the classes are only accessible to
code that lives in corlib and nowhere else.

> (3) Does Mono have a registry?
> 
> The .net calendar classes are using registry entries (e.g. HKCU/Control
> Panel/International/AddHijriDate) to set defaults. Currently I'm
> providing defaults in the source code and added a new property for
> AddHijriDate to control the value. Way to go?

At this point we do not have a registry.  I would suggest that you do
either one of:

	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. 

> (4) How compatible is Mono to .net bugs and limitations?
> 
> The GregorianCalendar class of .net has a bug in the argument handling
> of some member. I fixed it in my implementation, which could break
> broken code who uses wrong arguments.

Keep the bug fixed version in place, and please edit
mcs/class/docs/API-docs.  We are sending that file periodically to
Microsoft so they can fix/document the right behavior. 

It is my felling that the people in the .NET team are actively fixing
bugs in the class libraries, so it is better for now to have the bug
fixed version.  If this becomes a problem, in the future we can add the
bug compatibility mode. 

> For some non-obvious reason the .net HebrewCalendar implementation
> allows only a window (gregorian calendar years 1582 to 2240). I could do
> better than that, currently I decided to be compatible to .net and throw
> a ArgumentOutOfRange exception for such cases. I hope nobody expects me to
> support always the same exception message string than .net.

You do not need to support the same error messages, do not worry about
that.   If you find further limitations in the API, please document
those in the API-docs file and we will try to get those resolved as we
go. 

> It will take some time for me to provide the patch, because
> documentation and NUnit work have also to be done.

Excellent!  I can open a CVS account for you, check:

	http://www.go-mono.com/ccvs.html

For the details.

best wishes,
Miguel.