diff options
Diffstat (limited to 'doc/devel-faq')
| -rw-r--r-- | doc/devel-faq | 190 |
1 files changed, 0 insertions, 190 deletions
diff --git a/doc/devel-faq b/doc/devel-faq deleted file mode 100644 index 9ca89285219..00000000000 --- a/doc/devel-faq +++ /dev/null @@ -1,190 +0,0 @@ -* 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. - |