devel-faq

* 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$, $Author$,
   $Date$, 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.