[Mono-list] Troubles with mint

Miguel de Icaza miguel@ximian.com
25 Sep 2001 01:21:39 -0400


> The beauty of this is that you don't need to conditionally compile the
> class libraries.  The interface contains all of the platform specific
> items.  The actual classes used implement the interface and are choosen
> by a class factory that talks to the runtime to find out what platform
> we're on.  Here is an example:

Sean,

   There is no need to compile support for every operating system into
the same assembly.  Problems with conditional compilation should not
be an excuse for being sloppy and having an "Operating System" factory
interface. 

   Having a factory interface only means that every access to an OS
facility will have to go through an extra layer of indirection. 

   I do like the concept of being able to ship a single assembly, but
I am afraid that if we go down this road, we wont have support in the
new build setup for conditional compilation that we might want to
have.  

   A few reasons I can think of:

	* A subset of the libraries for "embedded systems".  The
          various ECMA profiles state that you might want to have a
          "level 1" implementation that does for instance lack
          floating point.

	* Compiling code that makes efficient use of internalcalls for
          a JITer/runtime engine.  Maybe not Mono's.

	* Really troublesome bits are implemented mostly as
          internalcalls and will probably be runtime dependent.

	  They might even be different in Mono (interpreter vs JIT).
          Think strings, threads and the GC interface.  And we do not
          want to incur the extra performance penalty of an
          indirection because of this.

So even if the speed is not an issue for things like `open' (because
who cares about open being a few cycles faster), I do not want this to
be the reason why we do not have conditional compilation.

If you can setup conditional compilation I would rest more peacefully,
and I could even be convinced down the road for using your
interface-based approach.

Miguel.