New test.
[mono.git] / web / class-library
1 * The Class Library
2
3         The Class Library should be compatible with Microsoft's .NET
4         implementation.
5
6         Please see the <a href="class-status.html">Class Status</a>
7         page for a status of who is working on which classes.
8         
9         We will write as much code as possible in C#. We may need to
10         interface with code written in C to gain access to the
11         functionality of libraries like libart, Gtk+, and libc.
12
13 ** Contributing
14
15         We welcome contributions to the the Class Library.  To get
16         started, check the status page for information about which
17         APIs are being worked on, and how to get in touch with 
18         individual maintainers.  
19
20         If you want to work on a class, first check the <a
21         href="download.html">Classes Distribution</a> to see if it is
22         not implemented yet, if not, check the <a
23         href="class-status.html">Class Status</a> to see if someone is
24         already working on it, and maybe contact them.
25
26         If nobody is working on it, mail <a
27         href="mailto:mono-list@ximian.com">mono-list@ximian.com</a>
28         with the class you want to implement and CC <a
29         href="mailto:miguel@ximian.com">miguel@ximian.com</a>.
30
31         You can also track live the activities of the Mono CVS module
32         by subscribing to the <a
33         href="http://lists.ximian.com/mailman/listinfo/mono-cvs-list">mono-cvs-list</a>
34
35
36 ** Missing features
37
38         Our class libraries miss some features, for example, most classes
39         do not implement the serialization bits at all, it would be a good
40         contribution to add this to each class.
41
42         This is a simple task, but it needs to be done in a compatible way
43         with the Microsoft.NET classes: using the same arguments to serialize
44         and reincarnate data.
45
46 ** Layout
47
48         The Class Library resides in the `mcs' module in the directoy
49         `class'.
50         
51         Each directory in the directory represents the assembly where
52         the code belongs to, and inside each directory we divide the
53         code based on the namespace they implement.
54
55         There are two cases when we should consider portability: when
56         we are dealing with a couple of classes only that differ from
57         system to system (Consider System.Net and System.IO for Win32
58         and Unix).  In those cases we will just place the files for
59         example on <t>corlib/System/System.IO/Unix-Console.cs</t> and
60         <t>corlib/System/System.IO/Win32-Console.cs</t>.
61
62         For classes that might differ more (for example, the
63         implementation of Windows.Forms), we might have different
64         directories altogether: <t>System.Windows.Forms/Win32</t>,
65         <t>System.Windows.Forms/Gtk+</t> and
66         <t>System.Windows.Forms/Cocoa</t>.
67
68 ** Using existing components from GNOME.
69
70         Our current plan is to implement the GUI tools on top of
71         Gtk+.  The only obstacle here is that applications from Windows
72         might expect to be able to pull the HWND property from the
73         widgets and use PInvoke to call Windows functions.
74
75 ** Class Library and Win32 dependencies.
76
77         There are a few spots where the Win32 foundation is exposed to
78         the class library (for example, the HDC and HWND properties in
79         the GDI+). Casual inspection suggests that these can be
80         safely mapped to Gdk's GC and GdkWindow pointers without
81         breaking anything.
82
83         The only drawback is that support for PInvoke of Win32 code
84         won't be available.  An alternate solution would be to use
85         portions of Wine, or even to use Wine as our toolkit.
86
87 *** Initial GDI+ and WinForms implementation
88
89         The initial implementation will use Gtk+ as the underlying
90         toolkit. Since GTK+ has already been ported to many windowing
91         systems other than X (including frame buffer, Win32, and BeOS)
92         its use should cover most applications for most users. 
93         
94 *** Database access
95
96         We will implement ADO.NET functionality by reusing <a
97         href="http://www.gnome-db.org">GNOME-DB</a>. This is an ideal
98         choice, since GNOME-DB was implemented precisely to provide an
99         ADO-like system for GNOME.
100
101 *** Component Integration
102
103         We will provide a new namespace to use GNOME specific features
104         as well as a namespace to host Bonobo interfaces and classes
105         in Mono.  
106
107 ** Licensing
108
109         The class library is being licensed under the terms of the 
110         <a
111         href="http://www.opensource.org/licenses/mit-license.html">MIT
112         license.</a>  This is the same license used by the X11 window
113         system.
114
115 ** Class Library testing
116
117         We need to write regression tests that will verify
118         the correctness of the class library, compiler, and JIT
119         engine.
120
121         Please write your regression tests using <a
122         href="http://nunit.sourceforge.net">NUnit</a>
123
124 ** Coding conventions
125
126         Please follow the conventions on the ECMA specification (On
127         the Annex Partition) for your coding your libraries. 
128
129         Use 8 space tabs for writing your code (hopefully we can keep
130         this consistent).  If you are modifying someone else's code, try
131         to keep the coding style similar.
132
133         For a rationale on 8 space tabs, read Linus Torvald's Coding
134         Style guidelines in the Linux kernel source for a rationale. 
135
136 *** Missing implementation bits
137
138         If you implement a class and you are missing implementation bits,
139         please put in the code the word "TODO" and a description of what
140         is missing to be implemented.
141
142 *** Tagging buggy code
143
144         If there is a bug in your implementation tag the problem by using
145         the word "FIXME" in the code, together with a description of the 
146         problem.
147
148         Do not use XXX or obscure descriptions, because otherwise people
149         will not be able to understand what you mean.
150
151 *** Tagging Lame specs
152
153         Sometimes the specification will be lame (consider Version.ToString (fieldCount)
154         where there is no way of knowing how many fields are available, making the API
155         not only stupid, but leading to unreliable code).
156
157         In those cases, use the keyword "LAMESPEC".
158
159 ** Namespaces
160
161         We are using a number of namespaces in the class libraries for
162         private classes when we need them, you are encouraged to use these:
163
164 <pre>
165 Mono
166  .Languages     // General Compiler classes
167    .CSharp      // Specific C# parsing/tokenizing classes
168    .MonoBASIC   // Specific VB.NET/MonoBASIC parsing/tokenizing classes
169    .Python      // Specific Python parsing/tokenizing classes
170  .Runtime
171    .LateBind    // General latebinding-support for MonoBASIC/Python
172    .MonoBASIC   // Specific runtime classes for MonoBASIC programs
173    .Python      // Specific runtime classes for Python programs
174  .Web
175    .UI
176      .Utils     // Gaurav utility classes
177 </pre>
178
179 ** FAQ
180
181 Frequently asked questions about the class library:
182
183 Q: I am writing a new class that overrides one of the system classes,
184    and I am getting a 1595 warning from the compiler.  Should we use a
185    different namespace?
186
187 A: There is a quick solution to the problem, you can pass the command
188    line argument /nowarn:1595 and this will effectively let you use
189    your implementation of the code, while overriding the ones from the
190    system assemblies.