[Mono-list] Re: Mono CVS: mcs gvaish
Tue, 04 Dec 2001 10:03:45 +1000
A Rafael D Teixeira wrote:
> First, just one of my comments:
> I donīt know why Rhys has objections to Mono root namespace. Would he ask
> Microsoft not to use the Microsoft root namespace? Would he prefer to have a
> Ximian namespace (a company-based namespace instead of project-based
If the code is truly Mono-specific, or a Ximian product
like mcs and MonoBASIC, then I have no objection. But
if the library is intended to be general-purpose, then I would
prefer that generic names be used like "OpenSystem", and
that greater care be taken to isolate the details from particular
The reason for this is simple: as the author of Portable.NET,
there may be some parts of the Mono class library that I
can reuse in my product, under the terms of the GPL. There
are two cases: entire package, and individual pieces.
Let's say I wanted to reuse MonoBASIC. This is a good
example, because I have no interest in writing my own
version of BASIC. I would take the entire assembly and
its libraries and wouldn't care how it is named internally or
externally. I'm interested only in the package. Call the
namespace whatever you want. It's a product in its own right.
It would be nice if you used "OpenSystem.Languages.Basic",
but I don't mind.
The other case is taking an individual namespace or class
from a Mono library for use in pnetlib. Take the Mono
"System.Security.Cryptography" stuff for example.
Let's say I wanted to reuse this rather than waste my
time building yet another crypto layer.
To be reusable the code must be well-isolated within
"corlib". It cannot just use "Mono.CoolStuff" or any
other internal class that only Mono's "corlib" has. If it
does, I have a nightmare on my hands trying to build
adapter classes to emulate the behaviour of the
dependencies, without dragging the rest of Mono
along for the ride.
[Aside: the crypto guys haven't done this yet - it is
a hypothetical example. No offence intended. But it
could become an issue once the crypto guys add locale
support for their strings].
The fact that "Mono.CoolStuff" is internal is irrelevant.
What is relevant is that the programmers have made
an assumption that their code will always be used in
Mono and nowhere else.
This is what I mean by thinking about other projects.
If your code is isolatable, then make sure you isolate it.
Use standard ECMA API's to talk to the rest of the
world where possible, and provide a clean and generic
interface where ECMA is insufficient. Do not assume
what the rest of the world is called.
My suggestion of using "OpenSystem" instead of "Mono"
for such namespaces is intended to get other programmers
to think in a generic mindset so that their code becomes
more useful to other projects, instead of less useful.
I'm desperately trying to find some way that our two
projects can co-operate in a useful manner. Co-operation
does not mean you can make it up as you go along and
I'm forced to work around your design bugs. It means
we have to meet in the middle, defining clear and generic
interfaces between components.