[Mono-dev] Base Class Library extending...

[Jonathan Pryor]

On Sat, 2008-08-09 at 17:15 +0200, Robert Jordan wrote:
> Roman S.V. wrote:
> > Hi!
> >   What about extending a BCL (Base Class Library) functionality inside mono?
> > If course, these extensions are mon-specific. I want to suggest my open
> > source project named as "Standard Extension Library"
> > (www.codeplex.com/stdextlib), which provides useful BCL extensions. I think
> > that this project can helps Mono to increase it flexibility and feature
> > list. What conditions must be allowed for including my project in the Mono?
> 
> Mono has its own extension library in development:
> 
> http://anonsvn.mono-project.com/viewcvs/branches/rocks-playground/

Nice as it is to refer to rocks-playground, you should at least mention
the "original" Mono.Rocks:

	http://anonsvn.mono-project.com/source/trunk/rocks/

rocks-playground is what happens when I start proposing several new
extension methods in Mono.Rocks, far more than the maintainers can keep
up with, and then I start replacing the original methods that were in
Mono.Rocks (e.g. int.Times(), int.UpTo(), etc.), and then go on a
*major* Haskell kick and implement most of the Haskell list methods [0]
as C# extension methods [1]...

In short, trunk is a (smallish) collection of useful utility methods,
and rocks-playground is witness to my insanity.  Which isn't necessarily
a _bad_ thing, mind you...

Now that I'm perusing Roman's Standard Extension Library, I have a few
comments about it:

1. As a matter of style (and pollution), please do *not* place your
extension methods into the same namespaces as the types you're extending
(e.g. don't place StringExtensions into the System namespace).

The reason for this is that your users will want a way to disable your
extension methods on a case-by-case basis (e.g. your extension methods
are conflicting with someone elses extension methods), and if you use
the same namespace as the type you're extending this becomes quite
difficult to do.  (They would need to remove the `using System;` line,
for example, and use e.g. System.Array if they wanted to avoid your
extension methods in one file but use them elsewhere.)

This is "not nice," shall we say, and will contradict the FxDG [2].

2. It could use some simplification, and shouldn't reimplement extension
methods that are already part of LINQ.

For example, your System.Collections.IEnumerableExtensions.Convert() is
System.Linq.Enumerable.Cast() or System.Linq.Enumerable.OfType(), and
your System.Collections.Generic.IEnumerableExtensions.Convert() is
basically System.Linq.Enumerable.Select(), your .Exists() is
LINQ's .Any(), your .Find() is LINQ's .Where().First(), etc.

Furthermore, I see no need for most of your array extension methods to
actually be restricted to arrays; surely .AsString() could work on
IEnumerable<T>, couldn't it?

Finally, you ask:

> What conditions must be allowed for including my project in the Mono?

It depends on what you mean by "includ[e] your project in mono."  If you
mean "use Mono's svn," it would be up to miguel but I suspect the
minimum would likely be to relicense as MIT/X11 and to follow Mono's
directory layout and source conventions, e.g. a directory layout of:

	class/AssemblyName/System
	class/AssemblyName/System.Collections
	class/AssemblyName/System.Collections.Generic

See http://anonsvn.mono-project.com/source/trunk/mcs/class/corlib/ for
an example.

The sources should also be cleaned up to fix the issues I raised above.

If by "includ[e] your project in mono" you mean "have your assembly
included with the main Mono installer and packages," this is less likely
to happen due to maintenance reasons.  Novell needs to maintain all
sources in the main packages for at least 5 years from release (for
security updates), and API/ABI stability needs to be maintained ~forever
for backward compatibility; increasing the number of bundled 3rd party
assemblies makes this difficult, particularly if the "upstream" versions
won't maintain API/ABI stability (i.e. Novell effectively gets an
ancient fork that is kept only for backward compatibility and is never
updated; this is what happened with Mono.GetOptions

Last I heard, no additional 3rd party assemblies would be included with
Mono in a "public use" basis, so this would *include* Mono.Rocks and
NDesk.Options, among lots of other useful third party libraries...

Which is why we have Guidelines about using 3rd party libraries:

http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs

Of course, miguel has final say in these manners; this is just my
(likely wrong) memory...

 - Jon

[0]
http://haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html

[1]
http://anonsvn.mono-project.com/source/branches/rocks-playground/Mono.Rocks/IEnumerable.cs

Between System.Linq.Enumerable and IEnumerableRocks, I think ~all of the
Haskell list methods except the *By and generic* methods are now
available in C#, if only by different names...

[2]
http://blogs.msdn.com/mirceat/archive/2008/03/13/linq-framework-design-guidelines.aspx

        "Do not put extension methods in the same namespace as the
        extended type, unless it is for adding methods to interfaces, or
        for dependency management. In the latter case, the type would be
        in a different assembly."