diff options
Diffstat (limited to 'web/devel-faq')
| -rw-r--r-- | web/devel-faq | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/web/devel-faq b/web/devel-faq new file mode 100644 index 00000000000..9ca89285219 --- /dev/null +++ b/web/devel-faq @@ -0,0 +1,190 @@ +* Developer FAQ + +** New classes + +Q: Should we write classes which are not part of the .NET or ECMA specs? + +A: Yes. The ECMA and .NET specifications are far from complete, and + to produce a complete platform we will need a number of other + classes and components. + + Any new classes that are not part of .NET or ECMA should be + designed to be reusable on anyone's CLI implementation. So that + Windows developers can also use any new classes that we come up + with. + + We have a few existing <a href="ideas.html">Ideas on missing + classes</a> + +** Language Compatibility + +Q: What is the magic that allow multiple languages to co-exist? + +A: From Fergus Henderson: + +<i><blockquote> +There are different levels of interoperability. +The ECMA spec defines different categories of +CLS (Common Language Specification) conformance. +There are also some useful categories that don't +correspond to any of the levels defined in the ECMA spec. +In increasing degree of difficulty, your language implementation +can + + <ul> + * (a) just generate IL + + * (b) be a CLS "consumer", which means that it can read in + meta-data describing component interfaces, + and that it provides a way to declare variables of + CLS-complaint types and to call CLS-complaint methods. + + * (c) be a CLS "extender", which means that it can in addition + derive from CLS-compliant classes + and implement CLS-compliant interfaces + + * (d) be able to produce components with *any* CLS-compliant + component interface. + </ul> + +Supporting some of these may require extending your language. However, +you can get quite a lot of interoperability by just putting appropriate +functionality in your compiler, without extending your language. + +For some things, e.g. ASP.NET, your language implementation also needs to be +able to + + <ul> + * (e) consume CodeDom trees. CodeDom trees are an abstract + representation of programs in a form similar to a C# parse + tree, with embedded code snippets (unparsed strings). + Given a CodeDom tree, with the snippets in your language, + your language implementation needs to generate a (i) .NET + assembly and possibly also (ii) a source file in your language. + + * (f) produce CodeDom trees. For some applications, + your language implementation also needs to be able to + round-trip from CodeDom -> your language -> CodeDom. + </ul> + +and for some things it needs to + + <ul> + * (g) generate *verifiable* IL + </ul> + +So when you hear all the hype about how language XYZ is a +".NET language", make sure you ask which of these different +things are supported. + +[For the record, Mercury currently supports (a). We're working on +(b) and (g), and on parts of (c) and (e). We're never going to do (f), I very +strongly doubt we'll ever do (d), and for (c) we might only ever support +implementing interfaces, not deriving from classes.] + +</blockquote></i> + +** PInvoke + +Q: What are the two major initiatives to implement PInvoke? + +A: Fergus Henderson answers: + +<i><blockquote> +Many of the .NET APIs will need to be implemented using code that calls C/Unix +APIs, such as stat(). The standard way of interfacing with native code from +.NET code is to use "PInvoke". However, there is a difficulty: many of +these APIs are defined in terms of types such as C's `long' or `size_t' +or the Posix `struct stat' whose representation varies depending on the +platform (architecture/OS/C compiler). There's no *portable* way of +accessing those from .NET managed code. + +So, there are a couple of different approaches. +One possibility is to access such routines by writing a wrapper, e.g. in C, +that provides the same functionality without using types with a system-dependent +representation. The wrapper can then be directly accessed from portable +.NET code. The .NET code remains both source- and binary-portable; +the wrapper code is source-portable, but needs to be compiled +seperately for each target platform. The drawback of this approach is +that you have to write a lot of cumbersome wrapper code. + +Another possibility is to extend the .NET VM with support for an +additional custom attribute, e.g. "[PosixType]". The VM would then +represent types tagged with this attribute in the same way that the +underlying system represents those types. With this approach, no +wrapper code would be needed. A drawback of this approach is that it +pushes quite a bit of complexity into the VM; the VM would have to know +the native representation of all types annotated with this attribute. +Another drawback is that code using this extension might not work on +different VMs. + +There have also been some other suggestions, but those are the two that +I think are the best. +</blockquote></i> + +Q: What is the problem implementing PInvoke? + +A: Again, from Fergus Henderson: + +<i><blockquote> +There's no problem implementing PInvoke as specified in the ECMA +specs and/or MS documentation. It's just that PInvoke by itself +doesn't solve all of the problems; in particular it doesn't solve +the problem of C types whose representation is different on different +systems. +</blockquote></i> + +** CVS use + +Q: Why do we keep ChangeLogs and make the CVS commit messages be the + same? One could be generated from the other + +A: There are a number of reasons for keeping ChangeLog files as well as + CVS commit files: + + <ul> + * Offline programming: when people are traveling, CVS logs are + not available. + + * Slow CVS access: Many people work over modem lines (very + typical for contributors in Europe, Asia, Latin America) + using CVS is slow and might not be available to you (cvs + server down, no anoncvs server available). + + * ChangeLogs travel in a released tarball package, so it is + possible to study the rationale of changes even after a + project is long "released", or you only have the sources for + the code. + + * ChangeLog are not metadata for each file, they are live + files that you can browse in the package that is being + distributed. + </ul> + +Making the CVS commit message be the same as the ChangeLog has other +benefits: + + <ul> + * You can track down with `cvs log' what things were changed, + and match those to meaningful reports on the intentions of + the commit. + + * When reading the commits-list, you can get a glimpse of the + changes without having to diff out or cvs update your tree. + + * You can read off-line the changes that are being made + (asyncrouns operation). + </ul> + +This mechanism works very well for GNOME and other projects. + +Q: Should I use any of the special RCS keywords like $Id: devel-faq,v 1.1 2001/07/31 21:13:05 miguel Exp $, $Author: miguel $, + $Date: 2001/07/31 21:13:05 $, or $Revision: 1.1 $? + +A: Please avoid using those in the source code in the CVS. They + are not really useful, and they cause a lot of conflicts when + people have separate CVS trees. + + It was a nightmare with the Linux kernel when two people had their + private CVS trees and were submitting patches to the core. + |