I was recently browsing the
code source of Managed Extensibility Framework and realized
that this future part of .NET 4, full of tricky and advanced ideas, was naively relying on strings
to describe files and directories paths. It seems that the version 4 of .NET will
miss the need for a decent path API. There is the class System.IO.Path
but it is feature limited, full of flaws and pitfalls (to not say bugs) and it fosters
users to encode their paths into raw strings. It seems to me that using strings to encode paths is as primitive as using String.IndexOf(“<tag>”) to parse some XML.
As many other applications,
the tool NDepend needs
to perform many complex paths operations. This includes:
- Relative / absolute path
conversion + Path rebasing.
- Path normalization API
- Path validity check API
- Path comparison API
- List of path operations
(TryGetCommonRootDirectory, GetListOfUniqueDirsAndUniqueFileNames, list
In mid 2007, during the development of NDepend we came to the
point where relying on the naïve and flawed System.IO.Path
was just not acceptable anymore. We then invested a few weeks in building our
own strong-typed path library NDepend.Helpers.FileDirectoryPath,
that we released Open-Source on CodePlex. The library is bug-free (at least
there is no known bug) 100% covered by tests but still, it didn’t attract the mass (only 477
downloads in 14 months). Moreover I don’t know any other equivalent library (do
you know any?).
The conclusion is
that in 2009 and beyond, doing something as mainstream as handling paths
operations in .NET, will still be a pain!
This reminds me the C#
non-nullable types debate
where half of the bugs in .NET code still comes from the pesky NullReferenceException.
IMHO concerning this issue, the future .NET 4 contracts API
will help a bit, but certainly not as much as a proper non-nullable strong
typing integration at language and platform level. Sadly, Anders Hejlsberg
recognized that the absence of non-nullable types is their biggest mistake in
designing C# and .NET
and cut any hope for seeing them one day.
A.H: You sort of end up going, well ok,
if we ever get another chance in umpteen years to build a new platform, we’ll
definitely get this one (i.e non-nullable types) right.
The problem is that both
Microsoft and its partners have now capitalized for almost a decade in .NET and won’t
likely shift to another platform before a very long time. Maybe I am narrow-minded
but I really can’t think of the post .NET era.
- The last years shown that investment in research and innovation from the Java
world cannot compare to what MS is doing. Since LINQ in 2007 and even
.NET generics in 2005, Java doesn’t lead the way anymore in technical
innovation and they won’t
likely be able to change this trend.
- Microsoft invests
massively into .NET for all its own products and it looks like it is just the
beginning. I can’t think of Microsoft replacing .NET with something else soon!
- And except the Java community
or Microsoft, who else is able today to produce a mainstream platform?
Debug.Assert(… != null); or if you prefer CodeContract.Requires(
… != null) will continue to be our friends for a very, very long time.