web/devel-faq

   1 * Developer FAQ
   2
   3 ** New classes
   4
   5 Q: Should we write classes which are not part of the .NET or ECMA specs?
   6
   7 A: Yes.  The ECMA and .NET specifications are far from complete, and
   8    to produce a complete platform we will need a number of other
   9    classes and components.
  10
  11    Any new classes that are not part of .NET or ECMA should be
  12    designed to be reusable on anyone's CLI implementation.  So that
  13    Windows developers can also use any new classes that we come up
  14    with.
  15
  16    We have a few existing <a href="ideas.html">Ideas on missing
  17    classes</a>
  18
  19 ** Language Compatibility
  20
  21 Q: What is the magic that allow multiple languages to co-exist?
  22
  23 A: From Fergus Henderson:
  24
  25 <i><blockquote>
  26 There are different levels of interoperability.
  27 The ECMA spec defines different categories of
  28 CLS (Common Language Specification) conformance.
  29 There are also some useful categories that don't
  30 correspond to any of the levels defined in the ECMA spec.
  31 In increasing degree of difficulty, your language implementation
  32 can
  33
  34         <ul>
  35         * (a) just generate IL
  36
  37         * (b) be a CLS "consumer", which means that it can read in
  38           meta-data describing component interfaces,
  39           and that it provides a way to declare variables of
  40           CLS-complaint types and to call CLS-complaint methods.
  41
  42         * (c) be a CLS "extender", which means that it can in addition
  43           derive from CLS-compliant classes
  44           and implement CLS-compliant interfaces
  45
  46         * (d) be able to produce components with *any* CLS-compliant
  47         component interface.
  48         </ul>
  49
  50 Supporting some of these may require extending your language.  However,
  51 you can get quite a lot of interoperability by just putting appropriate
  52 functionality in your compiler, without extending your language.
  53
  54 For some things, e.g. ASP.NET, your language implementation also needs to be
  55 able to
  56
  57         <ul>
  58         * (e) consume CodeDom trees.  CodeDom trees are an abstract
  59         representation of programs in a form similar to a C# parse
  60         tree, with embedded code snippets (unparsed strings).
  61         Given a CodeDom tree, with the snippets in your language,
  62         your language implementation needs to generate a (i) .NET
  63         assembly and possibly also (ii) a source file in your language.
  64
  65         * (f) produce CodeDom trees.  For some applications,
  66         your language implementation also needs to be able to
  67         round-trip from CodeDom -> your language -> CodeDom.
  68         </ul>
  69
  70 and for some things it needs to
  71
  72         <ul>
  73         * (g) generate *verifiable* IL
  74         </ul>
  75
  76 So when you hear all the hype about how language XYZ is a
  77 ".NET language", make sure you ask which of these different
  78 things are supported.
  79
  80 [For the record, Mercury currently supports (a).  We're working on
  81 (b) and (g), and on parts of (c) and (e).  We're never going to do (f), I very
  82 strongly doubt we'll ever do (d), and for (c) we might only ever support
  83 implementing interfaces, not deriving from classes.]
  84
  85 </blockquote></i>
  86
  87 ** PInvoke
  88
  89 Q: What are the two major initiatives to implement PInvoke?
  90
  91 A: Fergus Henderson answers:
  92
  93 <i><blockquote>
  94 Many of the .NET APIs will need to be implemented using code that calls C/Unix
  95 APIs, such as stat().  The standard way of interfacing with native code from
  96 .NET code is to use "PInvoke".  However, there is a difficulty: many of
  97 these APIs are defined in terms of types such as C's `long' or `size_t'
  98 or the Posix `struct stat' whose representation varies depending on the
  99 platform (architecture/OS/C compiler).  There's no *portable* way of
 100 accessing those from .NET managed code.
 101
 102 So, there are a couple of different approaches.
 103 One possibility is to access such routines by writing a wrapper, e.g. in C,
 104 that provides the same functionality without using types with a system-dependent
 105 representation.  The wrapper can then be directly accessed from portable
 106 .NET code.  The .NET code remains both source- and binary-portable;
 107 the wrapper code is source-portable, but needs to be compiled
 108 seperately for each target platform.  The drawback of this approach is
 109 that you have to write a lot of cumbersome wrapper code.
 110
 111 Another possibility is to extend the .NET VM with support for an
 112 additional custom attribute, e.g. "[PosixType]".  The VM would then
 113 represent types tagged with this attribute in the same way that the
 114 underlying system represents those types.  With this approach, no
 115 wrapper code would be needed.  A drawback of this approach is that it
 116 pushes quite a bit of complexity into the VM; the VM would have to know
 117 the native representation of all types annotated with this attribute.
 118 Another drawback is that code using this extension might not work on
 119 different VMs.
 120
 121 There have also been some other suggestions, but those are the two that
 122 I think are the best.
 123 </blockquote></i>
 124
 125 Q: What is the problem implementing PInvoke?
 126
 127 A: Again, from Fergus Henderson:
 128
 129 <i><blockquote>
 130 There's no problem implementing PInvoke as specified in the ECMA
 131 specs and/or MS documentation.  It's just that PInvoke by itself
 132 doesn't solve all of the problems; in particular it doesn't solve
 133 the problem of C types whose representation is different on different
 134 systems.
 135 </blockquote></i>
 136
 137 ** CVS use
 138
 139 Q: Why do we keep ChangeLogs and make the CVS commit messages be the
 140    same?  One could be generated from the other
 141
 142 A: There are a number of reasons for keeping ChangeLog files as well as
 143    CVS commit files:
 144
 145    <ul>
 146         * Offline programming: when people are traveling, CVS logs are
 147           not available.
 148
 149         * Slow CVS access: Many people work over modem lines (very
 150           typical for contributors in Europe, Asia, Latin America)
 151           using CVS is slow and might not be available to you (cvs
 152           server down, no anoncvs server available).
 153
 154         * ChangeLogs travel in a released tarball package, so it is
 155           possible to study the rationale of changes even after a
 156           project is long "released", or you only have the sources for
 157           the code.
 158
 159         * ChangeLog are not metadata for each file, they are live
 160           files that you can browse in the package that is being
 161           distributed.
 162    </ul>
 163
 164 Making the CVS commit message be the same as the ChangeLog has other
 165 benefits:
 166
 167    <ul>
 168         * You can track down with `cvs log' what things were changed,
 169           and match those to meaningful reports on the intentions of
 170           the commit.
 171
 172         * When reading the commits-list, you can get a glimpse of the
 173           changes without having to diff out or cvs update your tree.
 174
 175         * You can read off-line the changes that are being made
 176           (asyncrouns operation).
 177    </ul>
 178
 179 This mechanism works very well for GNOME and other projects.
 180
 181 Q: Should I use any of the special RCS keywords like $Id$, $Author$,
 182    $Date$, or $Revision: 1.1 $?
 183
 184 A: Please avoid using those in the source code in the CVS.  They
 185    are not really useful, and they cause a lot of conflicts when
 186    people have separate CVS trees.
 187
 188    It was a nightmare with the Linux kernel when two people had their
 189    private CVS trees and were submitting patches to the core.
 190