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

[Jonathan Pryor]

On Sun, 2008-08-10 at 05:23 -0700, Roman S.V. wrote:
> OK, I'm ready to fix posted issues. There is my plan:
> 1) Refactor all methods and namespace according with *.Extensions root
> namespace.

I don't think this is a good idea, in particular from the FxDG:

        Avoid generic naming of namespaces dedicated to extension
        methods (e.g. “Extensions”) – rather, use a descriptive name –
        e.g. “Routing”.

I'm also rather leery of using "System" as the root namespace of an
types that Mono provides.  Mono does not introduce any new System.*
types or namespaces, and instead places them into Mono.* types and
namespaces.

So I'm ~reasonably sure that having
System.Extensions/System.Collections.Extensions/etc. namespaces is a Bad
Idea (TM), particularly because it'll give people the impression that
those types are also provided in .NET w/o needing an additional library.

Finally, I can't think of any actual benefit to splitting up extension
methods by namespace.  With your original design, developers would have:

	using System;
	using System.Extensions;
	using System.Collections;
	using System.Collections.Extensions;
	using System.Collections.Generic;
	using System.Collections.Generic.Extensions;
	using System.IO;
	using System.IO.Extensions;

ad infinitum.  It would "pollute" the source for, as best as I can
determine, little actual gain.  It seems like a net loss, actually.

Compare to:

	using System;
	using System.Collections;
	using System.Collections.Generic;
	using System.IO;
	using Mono.Rocks;

which is considerably shorter for the same result (as far as the set of
extension methods available).

We can also compare to what Microsoft does, where the System.Linq
namespace provides extension methods on types in System.Collections,
System.Collections.Generic, and System.Linq itself.

So I'm inclined to say that ~all your extension methods should be within
one namespace, unless there's a compelling reason not to.

> But some namespaces are
> created during library development. There are System.Collections.Processing,
> System.Windows.Cli and etc. They will not be renamed.

Again, I would refrain from creating/generating System.*-namespaced
types, as these would imply some degree of "standardization", i.e. that
the types and assemblies would already be provided by .NET w/o grabbing
an additional assembly.  It's not a good idea.

> 2) Replace all duplicated extensions;

Agreed.

> 3) Replace all extensions, which are developed inside of the Rocks project.

Agreed.

Also, you should add:

4) Write unit tests for *all* extension methods you provide.

Mono.Rocks already provides NUnit unit tests for all extension methods,
and this should be continued for all new extension methods as well.

> Now, tell me please, how level integration of the Standard Extension Library
> in Rocks can be performed?
> I thnik, there is two ways:
> 1) SEL is devoured by Rocks.SEL + Rocks = Rocks;
> 2) SEL is united with Rocks into one project. SEL + Rocks = ???;
> What's your idea?

My idea is that it comes down to naming.  Considering that, from my
perspective, having "System" anywhere in the namespace names is a Bad
Idea, the only way for "Standard Extension Library" to make much sense
is if you use the "Standard" namespace, which would look decidedly odd.

Alternatively, we could create a new name for the merged assembly, but
regardless any such assembly name should be based on the namespace names
used, if only to conform to typical .NET convention and not confuse
people.  (People are frequently confused when Mono.Unix types are in
Mono.Posix dll, for example.)

So my vote is (1), though if you have a nice non-System-containing
name/namespace pattern, (2) could be appealing.

 - Jon