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