Jon Skeet: Coding Blog : Java

Noda Time is born

skeet — Fri, 06 Nov 2009 18:02:31 GMT

There was an amazing response to yesterday's post – not only did readers come up with plenty of names, but lots of people volunteered to help. As a result, I'm feeling under a certain amount of pressure for this project to actually take shape.

The final name chosen is Noda Time. We now have a Google Code Project and a Google Group (/mailing list). Now we just need some code…

I figured it would be worth explaining a bit more about my vision for the project. Obviously I'm only one contributor, and I'm expecting everyone to add there own views, but this can act as a starting point.

I want this project to be more than just a way of getting better date and time handling on .NET. I want it to be a shining example of how to build, maintain and deploy an open source .NET library. As some of you know, I have a few other open source projects on the go, and they have different levels of polish. Some have downloadable binaries, some don't. They all have just-about-enough-to-get-started documentation, but not nearly enough, really. They have widely varying levels of test coverage. Some are easier to build than others, depending on what platform you're using.

In some ways, I'm expecting the code to be the easy part of Noda Time. After all, the implementation is there already – we'll have plenty of interesting design decisions to make in order to marry the concepts of Joda Time with the conventions of .NET, but that shouldn't be too hard. Here are the trickier things, which need discussion, investigation and so forth:

What platforms do we support? Here's my personal suggested list:

.NET 4.0
.NET 3.5
.NET 2.0SP1 (require the service pack for DateTimeOffset)
Mono (versions TBD)
Silverlight 2, 3 and 4
Compact Framework 2.0 and 3.5

What do we ship, and how do we handle different platforms? For example, can we somehow use Code Contracts to give developers a better experience on .NET 4.0 without making it really hard to build for other versions of .NET? Can we take advantage of the availability of TimeZoneInfo in .NET 3.5 and still build fairly easily for earlier versions? Do developers want debug or release binaries? Can we build against the client profile of .NET 3.5/4.0?
What should we use to build? I've previously used NAnt for the overall build process and MSBuild for the code building part. While this has worked quite well, I'm nervous of the dependency on NAnt-Contrib library for the <msbuild> task, and generally being dependent on a build project whose last release was a beta nearly two years ago. Are there better alternatives?
How should documentation be created and distributed?

Is Sandcastle the best way of building docs? How easy is it to get it running so that any developer can build the docs at any time? (I've previously tried a couple of times, and failed miserable.)
Would Monodoc be a better approach?
How should non-API documentation be handled? Is the wiki which comes with the Google Code project good enough? Do we need to somehow suck the wiki into an offline format for distribution with the binaries?

What do we need to do in order to work in low-trust environments, and how easily can we test that?
What do we do about signing? Ship with a "public" snk file which anyone can build with, but have a private version which the team uses to validate a "known good" release? Or just have the private key and use deferred signing?
While the library itself will support i18n for things like date/time formatting, do we need to apply it to "developer only" messages such as exceptions?
I'm used to testing with NUnit and Rhino.Mocks, but they're not the last word in testing on .NET – what should we use, and why? What about coverage?
Do we need any dependencies (e.g. logging)? If so, how do we handle versioning of those dependencies? How are we affected by various licences?

These are all interesting topics, but they're not really specific to Noda Time. Information about them is available all over the place, but that's just the problem – it's all over the place. I would like there to be some sort of documentation saying, "These are the decisions you need to think about, here are the options we chose for Noda Time, and this is why we did so." I don't know what form that documentation will take yet, but I'm considering an ebook.

As you can tell, I'm aiming pretty high with this project – especially as I won't even be using Google's 20% time on it. However, there's little urgency in it for me personally. I want to work out how to do things right rather than how to do them quickly. If it takes me a bit of time to document various decisions, and the code itself ships later, so be it… it'll make the next project that much speedier.

I'm expecting a lot of discussion in the group, and no doubt some significant disagreements. I'm expecting to have to ask a bunch of questions on Stack Overflow, revealing just how ignorant I am on a lot of the topics above (and more). I think it'll be worth it though. I think it's worth setting a goal:

In one year, I want this to be a first-class project which is the natural choice for any developers wanting to do anything more than the simplest of date/time handling on .NET. In one year, I want to have a guide to developing open source class libraries on .NET which tells you everything you need to know other than how to write the code itself.

A year may seem like a long time, but I'm sure everyone who has expressed an interest in the project has significant other commitments – I know I do. Getting there in a year is going to be a stretch – but I'm expecting it to be a very enlightening journey.

What's in a name (again)?

skeet — Thu, 05 Nov 2009 20:01:05 GMT

I have possibly foolishly decided to stop resisting the urge to port Joda Time to .NET. For those of you who are unaware, "use Joda Time" is almost always the best answer to any question involving "how do I achieve X with java.util.Date/Calendar?" It's a Java library for handling dates and times, and it rocks. There is a plan to include a somewhat redesigned version in some future edition of Java (JSR-310) but it's uncertain whether this will ever happen.

Now, .NET only gained the ability to work with time zones other than UTC and the local time zone (using only managed code) – it has a bit of catching up to do. It's generally easier to work with the .NET BCL than the Java built-in libraries, but it's still not a brilliant position to be in. I think .NET deserves good date/time support, and as no-one else appears to be porting Joda Time, I'm going to do it. (A few people have already volunteered to help. I don't know how easily we'll be able to divvy up the work, but we'll see. I suspect the core may need to be done first, and then people can jump in to implement different chronologies etc. As a side-effect, I may try to use this project as a sort of case in terms of porting, managing an open source project, and properly implementing a .NET library with useful versioning etc.)

The first two problems, however, are to do with naming. First, the project name. Contenders include:

Joda Time.NET (sounds like it would be an absolutely direct port; while I intend to port all the tricky bits directly, it's going to be an idiomatic port with appropriate .NET bits. It's also a bit of a mouthful.)
Noda Time (as suggested in the comments and in email)
TonyTime (after Tony the Pony)
CoffeeTime
TeaTime
A progression of BreakfastTime, CoffeeTime, LunchTime, TeaTime, DinnerTime and SupperTime for different versions (not a serious contender)
ParsleySageRosemaryAndThyme (not a serious contender)
A few other silly ones too

I suspect I'm going to go for CoffeeTime, but we'll see.

The second problem is going to prove more awkward. I want to mostly copy the names given in Joda Time – aside from anything else, it'll make it familiar to anyone who uses Joda Time in Java (such as me). Now one of the most commonly used classes in Joda is "DateTime". Using that name in my port would be a Bad Idea. Shadowing a name in the System namespace is likely to lead to very disgruntled users who may prove hard to regruntle before they abandon the library.

So what do I do? Go for the subtly different DateAndTime? Tie it to the library with CoffeeDateTime? Change it to Instant? (It'll derive from AbstractInstant anyway – assuming I keep the same hierarchy instead of moving to a composition model and value types.)

Obviously this is a decision which the "team" can make, when we've got one… but it feels like a decision which is lurking round the corner in a hostile way.

What I find interesting is that these are two very different naming problems: one is trying to name something in a relatively arbitrary way – I know I want something reasonably short and memorable for the overall name, but beyond that it doesn't matter too much. The other is trying to nail a very specific name which really has to convey its meaning clearly… but where the obvious name is already taken. Also interestingly, neither is a particularly good example of my most common issue with naming: attempting to come up with a two or three word noun for something that actually needs a whole sentence to describe it adequately.

Oh well – we'll see what happens. In another blog post I'll suggest some of the goals I have in terms of what I'm hoping to learn from the project, and how I'd like it to progress. In other words, expect a work of complete fiction…

If you're interested in helping out with the project, please mail me directly (rather than adding comments here) and as soon as I've set the project up, I'll invite you to the mailing list.

UPDATE: I've already got a few interested names, which is great. Rather than be dictatorial about this, I'll put it to a vote of the people who are willing to help out on it.

A different approach to inappropriate defaults

skeet — Thu, 14 May 2009 17:03:52 GMT

I've had a couple of bug reports about my Protocol Buffers port - both nicely detailed, and one including a patch to fix it. (It's only due to my lack of timeliness in actually submitting the change that the second bug report occurred. Oops.)

The bug was in text formatting (although it also affected parsing). I was using the default ToString behaviour for numbers, which meant that floats and doubles were being formatted as "50,15" in Germany instead of "50.15". The unit tests caught this, but only if you ran them on a machine with an appropriate default culture.

Aaargh. I've been struggling with a similar problem in a library I can't change, which uses the system default time zone for various calculations in Java. When you're running server code, the default time zone is almost never the one you want to use, and it certainly isn't in my case.

A similar problem is Java's decision to use the system default encoding in all kinds of bizarre places - FileReader doesn't even let you specify the encoding, which makes it almost entirely useless in my view.

So I've been wondering how we could fix this and problems like it. One option is to completely remove the defaults. If you always had to pass in a CultureInfo/Locale, TimeZoneInfo/TimeZone, Encoding/Charset when you call any method which might be culturally sensitive.

Making life easier (in .NET)

It strikes me that .NET has a useful abstraction here: the assembly as the unit of deployment. (Java's closest equivalent is probably a jar file, which probably gets messier.)

Within one assembly, I suspect in many cases you always want to make the same decision. For example, in protocol buffers I would like to use the invariant culture all the time. It would be nice if I could say that, and then get the right behaviour by default. Here are the options I'd like to be able to apply (for each of culture, time zone and character encoding - there may be others):

Use a culture-neutral default (the invariant culture, UTF-8, UTC)
Use a specific set of values (e.g. en-GB, Windows-1252, "Europe/London")
Use the system default values
Use whatever the calling assembly is using

Of course you should still have the option of specifying overrides on a per call basis, but I think this might be a way forward.

Thoughts? I realise it's almost certainly too late for this to actually be implemented now, but would it have been a good idea? Or is it just an alternative source of confusion?

Language proliferation

skeet — Tue, 12 May 2009 16:54:47 GMT

I've always been aware that .NET supports multiple languages (obviously) and that Microsoft has been experimenting with this to some extent. It's only recently struck me just to what extent this is the case though.

Here's a list - almost certainly incomplete - of .NET languages from Microsoft alone.

C#
VB (or VB.NET if you wish)
C++/CLI
F#
IronPython
IronRuby
Spec#
M (with Oslo)
Axum
Managed JScript
PowerShell
Cω
J# (not shipping any more, I believe)

Some of these are research languages which are more important for the ideas they've contributed to more mainstream ones at a later date than for anything else – but there's still a lot of effort represented in the list.

In addition, there are third party languages targeting .NET, such as Boo, IronScheme and Scala. (Wikipedia lists loads of them.)

Now, think back to the time before .NET. Was Microsoft actively experimenting with languages back then? Plenty of people were trying things against the JVM, but Sun was pretty much absent from that party. .NET seems to be a "missing ingredient" that has allowed smart folk at Microsoft to let their imaginations loose in ways which they couldn't previously. (Of course, not everyone in the language business at MS started there: Jim Hugunin was hired by Microsoft precisely because of his work on IronPython.)

I wonder how long this will continue.

Tower of Babel, or land of polyglots?

What does this mean for the average developer? Currently, if you're writing a non-web application in .NET, you really only need to know a single language – and any of them will do. (Plus potentially SQL of course…) Compare this with web developers who have to be intimately familiar with HTML, CSS and JavaScript – and the differences between various implementations.

How long will it be before backend developers are expected to know a dynamic language, a static OO language and a functional language? Does the benefit of mixing several languages in a project worth the impedance mismatch and the increased skillset requirements? I'm not going to make any predictions on that front – I can certainly see the benefits of each of these approaches in certain situations. They've been designed to play well together, but there are bound to be limitations and oddities: times when you need to change how you write your F# so that it's easily callable from C#, for example.

Whether or not you learn multiple languages to a professional level is one thing, but becoming familiar with them is a different matter. In the course of co-authoring Functional Programming for the Real World (where "co-author" is a bit of a stretch title - I've played more of an editorial role really, with the added bonus of picking on Tomas whenever I felt he was perhaps a little harsh towards C#) I've learned to appreciate many of F#'s qualities, but I don't really know the language. If someone asked me to write a complete application in it (rather than just a toy experiment) I'd be reaching for books every other minute. I hope I'll learn more over the course of time, but I doubt that I'll ever be sufficiently experienced in it to put it on my CV. The same goes for IronPython, although I'm considerably more likely to need Python at work than I am F#. (Python is one of the three "approved" languages at Google, along with Java and C++.) None of this means that time spent in these languages is wasted: I'll be able to apply a lot of what I've learned about F# to my C# coding, even if it will make me pine for things like pattern matching and asynchronous workflows periodically.

I think it's pretty much a given that these days we all need to bring a wide range of technologies to bear in most jobs. While it used to be just about feasible in the .NET 1.1 days to have a pretty good grasp of all the major aspects (ASP.NET for sites and web services, ADO.NET, WinForms, Windows services, class libraries, interop) it's just impossible these days. We learn something new when we need to - but usually against the background of a familiar language. How well would we cope if we had to learn whole new languages (to the level of being able to use them for production code) as often as we have to learn new libraries?

This worries me a little. I'm pleased to see that C# 4 is a much smaller change than the previous versions were. Admittedly I'd rather have had immutability support than dynamic, but that's just me... and that's the problem, too. While I worry about our ability to actually learn everything that's becoming available, it's all good stuff. Can there be "too much of a good thing"?

What I really don't want to see is developers having to know multiple languages, and everyone knowing them poorly. I'm a big believer in having a thorough understanding of your language, so that even if everything else is new, you can rely on your understanding of that aspect of your code. It would be a shame if the pressure of knowing many languages turned many of us into cargo cult programmers. The utopia would be for us all to turn into language renaissance developers. I suspect the reality will be somewhere between the two.

Still, as long as I get to keep helping authors write about languages I know almost nothing about, I'm sure I'll be happy...

What's in a name?

skeet — Fri, 27 Feb 2009 11:29:00 GMT

T.S. Eliot had the right idea when he wrote "The naming of cats":

The Naming of Cats is a difficult matter,
It isn't just one of your holiday games
...
When you notice a cat in profound meditation,
The reason, I tell you, is always the same:
His mind is engaged in a rapt contemplation
Of the thought, of the thought, of the thought of his name:
His ineffable effable
Effanineffable
Deep and inscrutable singular Name.

Okay, so developers may not contemplate their own names much, but I know I've certainly spent a significant amount of time recently trying to work out the right name for various types and methods. It always feels like it's just out of reach; tauntingly, tantalisingly close.

Recently I've been thinking a bit about what the goals might be in coming up with a good name. In particular, I seem to have been plagued with the naming problem more than usual in the last few weeks.

Operations on immutable types

A while ago I asked a question on Stack Overflow about naming a method which "adds" an item to an immutable collection. Of course, when I say "adds" I mean "returns a new collection whose contents is the old collection and the new item." There's a really wide range of answers (currently 38 of them) which mostly seem to fall into four categories:

Use Add because it's idiomatic for .NET collections. Developers should know that the type is immutable and act accordingly.
Use Cons because that's the term functional programming has used for this exact operation for decades.
Use a new method name (Plus being my favourite at the moment) which will be obvious to non-functional developers, but without being so familiar that it suggests mutability.
Use a constructor taking the old collection and the new item.

Part of the reasoning for Add being okay is that I originally posted the question purely about "an immutable collection" - e.g. a type which would have a name like ImmutableList<T>. I then revealed my true intention (which I should have done from the start) - to use this in MiniBench, where the "collection" would actually be a TestSuite. Everything in MiniBench is immutable (it's partly an exploration in functional programming, as it seems to fit very nicely) but I don't want to have to name every single type as Immutable[Whatever]. There's the argument that a developer should know at least a little bit about any API they're using, and the immutability aspect is one of the first things they should know. However, MiniBench is arguably an extreme case, because it's designed for sharing test code with people who've never seen it before.

I'm pretty sure I'm going to go with Plus in the end:

It's close enough to Add to be familiar
It's different enough to Add to suggest that it's not quite the same thing as adding to a normal collection
It sounds like it returns something - a statement which just calls Plus without using the result sounds like it's wrong (and indeed it would be)
It's meaningful to everyone
I have a precedent in the Joda Time API

Another option is to overload the + operator, but I'm not really sure I'm ready to do that just yet. It would certainly leave brief code, but is that really the most important thing?

Let's look at a situation with some of the same issues...

LINQ operators

Work on MoreLINQ has progressed faster than expected, mostly because the project now has four members, and they've been expending quite a bit of energy on it. (I must do a proper consistency review at some point - in particular it would be nice to have the docs refer to the same concepts in the same way each time. I digress...)

Most of the discussion in the project hasn't been about functionality - it's been about naming. In fact, LINQ is particularly odd in this respect. If I had to guess at how the time has been spent (at least for the operators I've implemented) I'd go for:

15% designing the behaviour
20% writing the tests
10% implementation
5% writing the documentation (just XML docs)
50% figuring out the best name

It really is that brutal - and for a lot of the operators we still haven't got the "right" name yet, in my view. There's generally too much we want to convey in a word or two. As an example, we've got an operator similar to the oft-implemented ForEach one, but which yields the input sequence back out again. Basically it takes an action, and for each element it calls the action and then yields the element. The use case is something like logging. We've gone through several names, such as Pipe, Tee, Via... and just this morning I asked a colleague who suggested Apply, just off the top of his head. It's better than anything we'd previously thought of, but does it convey both the "apply an action" and "still yield the original sequence" aspects?

The old advice of "each method should only do one thing" is all very well, and it clearly helps to make naming simpler, but with situations like this one there are just naturally more concepts which you want to get across in the name.

Let's stay on the LINQ topic, but stray a bit further from the well-trodden path...

The heart of Push LINQ: IDataProducer

I've probably bored most of you with Push LINQ by now, and I'm not actively developing it at the moment, but there's still one aspect which I'm deeply uncomfortable with: the core interface. IDataProducer represents a stream of data which can be observed. Basically clients subscribe to events, and their event handlers will be called when data is "produced" and when the stream ends.

I know IDataProducer is an awful name - but so far I haven't found anything better. IObservable? Ick. Overused and isn't descriptive. IPushEnumerable? Sounds like the client can iterate over the data, which they can't. The actual event names (DataProduced/EndOfData) are okay but there must be something better than IDataProducer. (Various options have been suggested in the past - none of them have been so obviously "right" as to stick in my head...)

This situation is slightly different to the previous ones, however, simply because it's such a pivotal type. You would think that the more important the type, the more important the name would be - but in some ways the reverse is true. You see, Push LINQ isn't a terribly "obvious" framework. I say that without shame - it's great at what it does, but it takes a few mental leaps before you really grok it. You're really going to have to read some documentation or examples before you write your own queries.

Given that constraint, it doesn't matter too much what the interface is called - it's going to be explained to you before you need it. It doesn't need to be discoverable - whereas when you're picking method names to pop up in Intellisense, you really want the developer to be able to guess its purpose even before they hover over it and check the documentation.

I haven't given up on IDataProducer (and I hope to be moving Push LINQ into MoreLINQ, by the way - working out a better name is one of the blockers) but it doesn't feel like quite as much of a problem.

Read-only or not read-only?

This final example came up at work, just yesterday - after I'd started writing this post. I wanted to refactor some code to emphasize which methods only use the read-only side of an interface. This was purely for the sake of readability - I wanted to make it easier to reason about which areas of the code modified an object and which didn't. It's a custom collection - the details don't matter, but for the sake of discussion let's call it House and pretend we're modelling the various things which might be in a house. (This is Java, hence House rather than IHouse.)

I'm explicitly not doing this for safety - I don't mind the fact that the reference could be cast to a mutable interface. The point is just to make it self-documenting that if a method only has a parameter in the non-mutating form, it's not going to change the contents of the house.

So, we have two interfaces, like this:

public interface NameMePlease
{
    Color getDoorColor();
    int getWindowCount();

    // This already returned a read-only collection
    Set<Furniture> getFurniture();
}

public interface House extends NameMePlease
{
    void setDoorColor(Color doorColor);
    void setWindowCount(int windows);
    void addFurniture(Furniture item);
}

Obviously the challenge is to find a name for NameMePlease. One option is to use something like ImmutableHouse or ReadOnlyHouse - but the inheritance hierarchy makes liars of both of those names. How can it be a ReadOnlyHouse if there are methods in an implementation which change it? The interface should say what you can do with the type, rather than specifying what you can't do - unless part of the contract of the interface is that the implementation will genunely prohibit changes.

Thinking of this "positive" aspect led me to ReadableHouse, which is what I've gone with for the moment. It states what you can do with it - read information. Again, this is a concept which Joda Time uses.

Another option is to make it just House, and change the mutable interface to MutableHouse or something similar. In this particular situation the refactoring involved would have been enormous. Simple to automate, but causing a huge check-in for relatively little benefit. Almost all uses are actually mutating ones. The consensus within the Google Java mailing list seems to be that this would have been the preferred option, all things being equal. One interesting data point was that although Joda Time uses ReadableInstant etc, the current proposals for the new date/time API which will be included in Java 7, designed by the author of Joda Time, don't use this convention. Presumably the author found it didn't work quite as well as he'd hoped, although I don't have know of any specific problems.

Conclusion

You'll probably be unsurprised to hear that I don't have a recipe for coming up with good names. However, in thinking about naming I've at least worked out a few points to think about:

Context is important: how discoverable does this need to be? Is accuracy more important than brevity? Do you have any example uses (e.g. through tests) which can help to see whether the code feels right or not?
Think of your audience. How familiar will they be with the rest of the code you're writing? Are they likely to have a background in other areas of computer science where you could steal terminology? Can you make your name consistent with other common frameworks they're likely to use? The reverse is true too: are you reusing a familiar name for a different concept, which could confuse readers?
Work out the information the name is trying to convey. For types, this includes working out how it participates in inheritance. Is it trying to advertise capabilities or restrictions?
Is it possible to make correct code look correct, and buggy code look wrong? This is rarely feasible, but it's one of the main attractions of "Plus" in the benchmark case. (I believe this is one of the main selling points of true Hungarian Notation for variable naming, by the way. I'm not generally a fan, but I like this aspect.)

I may expand this list over time...

I think it's fitting to close with a quote from Phil Karlton:

There are only two hard things in Computer Science: cache invalidation and naming things.

Almost all of us have to handle naming things. Let's hope most of us don't have to mess with cache invalidation as well.

Redesigning System.Object/java.lang.Object

skeet — Fri, 05 Dec 2008 17:52:44 GMT

I've had quite a few discussions with a colleague about some failures of Java and .NET. The issue we keep coming back to is the root of the inheritance tree. There's no doubt in my mind that having a tree with a single top-level class is a good thing, but it's grown a bit too big for its boots.

Pretty much everything in this post applies to both .NET and Java, sometimes with a few small changes. Where it might be unclear, I'll point out the changes explicitly - otherwise I'll just use the .NET terminology.

What's in System.Object?

Before we work out what we might be able to change, let's look at what we've got. I'm only talking about instance methods. At the moment:

Life-cycle and type identity

There are three members which I believe really need to be left alone.

We need a parameterless constructor because (at least with the current system of chaining constructors to each other) we have to have some constructor, and I can't imagine what parameter we might want to give it. I certainly find it hard to believe there's a particular piece of state which really deserves to be a part of every object but which we're currently missing.

I really don't care that much about finalizers. Should the finalizer be part of Object itself, or should it just get handled automatically by the CLR if and only if it's defined somewhere in the inheritance chain? Frankly, who cares. No doubt it makes a big difference to the implementation somewhere, but that's not my problem. All I care about when it comes to finalizers is that when I have to write them it's as easy as possible to do it properly, and that I don't have to write them very often in the first place. (With SafeHandle, it should be a pretty rare occurrence in .NET, even when you're dealing directly with unmanaged resources.)

GetType() or (getClass() in Java) is pretty important. I can't see any particular alternative to having this within Object, unless you make it a static method somewhere else with an Object parameter. In fact, that would have the advantage of freeing up the name for use within your own classes. The functionality is sufficiently important (and really does apply to every object) that I think it's worth keeping.

Comparison methods

Okay, time to get controversial. I don't think every object should have to be able to compare itself with another object. Of course, most types don't really support this anyway - we just end up with reference equality by default.

The trouble with comparisons is that everyone's got a different idea of what makes something equal. There are some types where it really is obvious - there's only one natural comparison. Integers spring to mind. There are other types which have multiple natural equality comparisons - floating point numbers (exact, within an absolute epsilon, and within a relative epsilon) and strings (ordinal, culture sensitive and/or case sensitive) are examples of this. Then there are composite types where you may or may not care about certain aspects - when comparing URLs, do I care about case? Do I care about fragments? For http, if the port number is explicitly specified as 80, is that different to a URL which is still http but leaves the port number implicit?

.NET represents these reasonably well already, with the IEquatable<T> interface saying "I know how to compare myself with an instance of type T, and how to produce a hashcode for myself" and IEqualityComparer<T> interface saying "I know how to compare two instances of T, and how to produce a hashcode for one instance of T." Now suppose we didn't have the (nongeneric!) Equals() method and GetHashCode() in System.Object. Any type which had a natural equality comparison would still let you compare it for equality by implementing IEquatable<T>.Equals - but anything else would either force you to use reference equality or an implementation of IEqualityComparer<T>.

Some of the principle consumers of equality comparisons are collections - particularly dictionaries (which is why it's so important that the interfaces should include hashcode generation). With the current way that .NET generics work, it would be tricky to have a constraint on a constructor such that if you only specified the types, it would only work if the key type implemented IEquatable<T>, but it's easy enough to do with static methods (on a non-generic type). Alternatively you could specify any type and an appropriate IEqualityComparer<T> to use for the keys. We'd need an IdentityComparer<T> to work just with references (and provide the equivalent functionaliy to Object.GetHashCode) but that's not hard - and it would be absolutely obvious what the comparison was when you built the dictionary.

Monitors and threading

This is possibly my biggest gripe. The fact that every object has a monitor associated with it was a mistake in Java, and was unfortunately copied in .NET. This promotes the bad practice of locking on "this" and on types - both of which are typically publicly accessible references. I believe that unless a reference is exposed explicitly for the purpose of locking (like ICollection.SyncRoot) then you should avoid locking on any reference which other code knows about. I typically have a private read-only variable for locking purposes. If you're following these guidelines, it makes no sense to be able to lock on absolutely any reference - it would be better to make the Monitor class instantiable, and make Wait/Pulse/PulseAll instance members. (In Java this would mean creating a new class and moving Object.wait/notify/notifyAll members to that class.)

This would lead to cleaner, more readable code in my view. I'd also do away with the "lock" statement in C#, making Monitor.Enter return a token implementing IDisposable - so "using" statements would replace locks, freeing up a keyword and giving the flexibility of having multiple overloads of Monitor.Enter. Arguably if one were redesigning all of this anyway, it would be worth looking at whether or not monitors should really be reentrant. Any time you use lock reentrancy, you're probably not thinking hard enough about the design. Now there's a nice overgeneralisation with which to end this section...

String representations

This is an interesting one. I'm genuinely on the fence here. I find ToString() (and the fact that it's called implicitly in many circumstances) hugely useful, but it feels like it's attempting to satisfy three different goals:

Giving a developer-readable representation when logging and debugging
Giving a user-readable representation as part of a formatted message in a UI
Giving a machine-readable format (although this is relatively rare for anything other than numeric types)

It's interesting to note that Java and .NET differ as to which of these to use for numbers - Java plumps for "machine-readable" and .NET goes for "human-readable in the current thread's culture". Of course it's clearer to explicitly specify the culture on both platforms.

The trouble is that very often, it's not immediately clear which of these has been implemented. This leads to guidelines such as "don't use ToString() other than for logging" on the grounds that at least if it's implemented inappropriately, it'll only be a log file which ends up with difficult-to-understand data.

Should this usage be explicitly stated - perhaps even codified in the name: "ToDebugString" or something similar? I will leave this for smarter minds to think about, but I think there's enough value in the method to make it worth keeping.

MemberwiseClone

Again, I'm not sure on this one. It would perhaps be better as a static (generic!) method somewhere in a class whose name indicated "this is for sneaky runtime stuff". After all, it constructs a new object without calling a constructor, and other funkiness. I'm less bothered by this than the other items though.

Conclusion

To summarise, in an ideal world:

Equals and GetHashCode would disappear from Object. Types would have to explicitly say that they could be compared
Wait/Pulse/PulseAll would become instance methods in Monitor, which would be instantiated every time you want a lock.
ToString might be renamed to give clearer usage guidance.
MemberwiseClone might be moved to a different class.

Obviously it's far too late for either Java or .NET to make these changes, but it's always interesting to dream. Any more changes you'd like to see? Or violent disagreements with any of the above?

Data Structures and Algorithms: new free eBook available (first draft)

skeet — Fri, 29 Aug 2008 19:25:17 GMT

I've been looking at this for a while: Data Structures and Algorithms: Annotated reference with examples. It's only in "first draft" stage at the moment, but the authors would love your feedback (as would I). Somehow I've managed to end up as the editor and proof-reader, although due to my holiday the version currently available doesn't have many of my edits in. It's a non-academic data structures and algorithms book, intended (as I see it, anyway) as a good starting point for those who know that they ought to be more aware of the data structures they use every day (lists, heaps etc) but don't have an academic background in computer science.

An implementation will be available in both Java and C#, I believe.

Automatic lambda expressions

skeet — Fri, 20 Jun 2008 16:33:00 GMT

This morning I happened to show a colleague (Malcolm Rowe) the neat trick of using nullable types and the null-coalescing operator (??) to implement compound comparisons in C#. He asked whether it wouldn't have been nicer to make this a library feature rather than a language feature. I'm all for putting features into libraries where possible, but there's a problem in this case: the ?? operator doesn't evaluate its right operand unless the left operand evaluates to null. This can't be replicated in a library. Or can it?

The obvious way to lazily evaluate an expression is to turn it into a closure. So, we can write out coalescing method as:

public static T CoalesceNulls<T>(T lhs, Func<T> rhs)
{
return lhs != null ? lhs : rhs();
}

That's quite an efficient way of doing it, but the assymetry isn't ideal. We can fix that by making the first argument a function too:

public static T CoalesceNulls<T>(Func<T> lhs, Func<T> rhs)
{
T first = lhs();
return first != null ? first : rhs();
}

One of the nice things you can do with the null-coalescing operator is use it for multiple expressions, e.g. a ?? b ?? c ?? d which will evaluate a, then (if it's null) evaluate b, then (if that's null) evaluate c etc. With the symmetry present we can now make this into a parameter array:

public static T CoalesceNulls<T>(params Func<T>[] functions)
{
    T current = default(T);
    foreach (Func<T> func in functions)
    {
        current = func();
        if (current != null)
        {
            break;
        }
    }
    return current;
}

(In some ways it's still more elegant to specify a bare T as the first parameter, as that ensures that at least you've got one function to call. The change required is pretty obvious.)

Now there are only two problems: invoking the method, and the performance characteristics. I'm going to ignore the latter - yes, you could end up with a significant performance hit creating all these closures all the time if you use this in performance critical code. There's not a lot of options available there, really. But what about the syntax for invoking the method?

In its current form, we can write the current a ?? b ?? c ?? d as CoalesceNulls(() => a, () => b, () => c, () => d)l. That's a wee bit ugly. Malcolm blogged about an alternative where the parameters could be declared on the declaration side) as calling for deferred execution, and automatically converted into closures by the compiler.

Just like Malcolm, I'm not terribly keen on this - for instance, I really like the fact that in C# it's always very clear when a parameter is being passed by reference, because there's the ref keyword on the caller side as well as the declaration side. Going against this would just feel wrong.

If we have to change the language and introduce new keywords or symbols, we're then back where we started - the whole idea was to avoid having to introduce ?? into the language. The plus side is that it could be "usage agnostic" - just because it could be used for a null-coalescing operator replacement doesn't mean it would have to be. However, this feels like using a sledgehammer to crack a nut - the number of times this would be useful is pretty minimal. The same argument could be applied to the null-coalescing operator itself, of course, but I think its utility - and the way it fits into the language pretty seamlessly - justifies the decisions made here.

Still, it was an interesting thought experiment...

Update: Since originally writing this (a few days ago, before the blog outage, Malcolm has been informed that Scala has precisely this capability. Just another reason for getting round to learning Scala at some point...

The Beauty of Closures

skeet — Tue, 06 May 2008 22:08:20 GMT

Fairly soon I'm going to write a blog post comparing the different proposals under consideration for Java 7 when it comes to closures. I thought it would be worth writing some background material on it first though, so I've put an article on the C# in Depth site.

I'm not entirely comfortable that I've captured why they're important, but the article can mature over time like a good wine. The idea is to counter the Blub Paradox (which I hadn't come across before, but I agree with completely - it's part of the effect I believe Steve McConnell was fighting against when talking about programming in a language).

Programming "in" a language vs programming "into" a language

skeet — Wed, 23 Apr 2008 18:47:15 GMT

I'm currently reading Steve McConnell's Code Complete (for the first time - yes, I know that's somewhat worrying) and there was one section was disturbed me a little. For those of you with a copy to hand, it's in section 4.3, discussing the difference between programming in a language and programming into a language:

Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.

Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Now don't get me wrong - I can see where he's coming from, and the example he then provides (Visual Basic - keeping the forms simple and separating them from business logic) is fine, but he only seems to give one side of the coin. Here's a different - and equally one-sided - way of expressing the same terms:

Programmers who program "in" a language understand that language's conventions and idioms. They write code which integrates well with other libraries, and which can be easily understood and maintained by other developers who are familiar with the language. They benefit from tools which have been specifically designed to aid coding in the supported idioms.

Programmers who program "into" a language will use the same ideas regardless of their target language. If their style does not mesh well with the language, they will find themselves fighting against it every step of the way. It will be harder to find libraries supporting their way of working, and tools may well prove annoying. Other developers who come onto the project later and who have experience in the language but not the codebase will find it hard to navigate and may well accidentally break the code when changing it.

There is a happy medium to be achieved, clearly. You certainly shouldn't restrict your thinking to techniques which are entirely idiomatic, but if you find yourself wanting to code in a radically different style to that encouraged by the language, consider changing language if possible!

If I were attacking the same problem in C# 1 and C# 3, I could easily end up with radically different solutions. Some data extraction using LINQ in a fairly functional way in C# 3 would probably be better solved in C# 1 by losing some of the functional goodness than by trying to back-port LINQ and then use it without the benefit of lambda expressions or even anonymous methods.

Accents and Conventions

That's just between different versions of the same language. Between different actual languages, it can get much worse. If you've ever seen Java code written in a C++ style or vice versa, you'll know what I mean. I've previously referred to this in terms of speaking a language with an accent - you can speak C# with a Java accent just as you can speak French with an English accent. Neither is pleasant.

At the lowest level, this is likely to be about conventions - and I'm pretty sure that when Steve writes "Invent your own coding conventions, standards, class libraries, and other augmentations" he doesn't actually mean us to do it in a gratuitous fashion. It can be worth deviating from the "platform favoured" conventions sometimes, particularly if those differences are invisible to clients, but it should always be done with careful consideration. In a Java project I worked on a few years ago, we took the .NET naming conventions for interfaces (an I prefix) and constants (CamelCasing instead of SHOUTY_CAPS). Both of these made the codebase feel slightly odd, particularly where Java constants were used near our constants - but I personally found the benefits to be worth the costs. Importantly, the whole team discussed it before making any decisions.

Design Patterns

At a slightly higher level, many design patterns are just supported much, much better by some languages than others. The iterator pattern is a classic example. Compare the support for it from Java 6 and C# 2. On the "client" side, both languages have specific syntax: the enhanced for loop in Java and the foreach loop in C#. However, there is one important difference: if the iterator returned by GetEnumerator implements IDisposable (which the generic form demands, in fact) C# will call Dispose at the end of the loop, no matter how that occurs (reaching the end of the sequence, breaking early, an exception being thrown, etc). Java has no equivalent of this. Imagine that you want to write a class to iterate over the lines in a file. In Java, there's just no safe way of representing it: you can make your iterator implement Closeable but then callers can't (safely) use the enhanced for loop. You can make your code close the file handle when it reaches the end, but there's no guarantee that will happen.

Then consider the "server" side of the iterator - the code actually providing the data. Java is like C# 1 - there's no specific support for implementing an iterator. In C# 2 and above, iterator blocks (i.e. methods with yield statements) make life much, much easier. Writing iterators by hand can be a real pain. Reading a file line by line isn't too bad, leaving aside the resource lifetime issue - but the complexity can balloon very quickly. Off by one errors are really easy to introduce.

So, if I were tackling a project which required reading text files line by line in various places, what would I do? In Java, I would take the reasonably small hit of a while loop in each place I needed it. In C# I'd write a LineReader class (if I didn't already have one!) and use a more readable foreach loop. The contortions involved in introducing that idea into Java just wouldn't be worth the effort.

At a much higher level, we get into whole programming styles and paradigms. If your natural inclination is to write imperative code, you're likely to create a mess (or get very frustrated) in a functional language. If the problem really does call for a functional language, find someone else to help you think in a more functional way. If the problem suits imperative programming just as well as it does functional programming, see if you can change the environment to something more familiar.

Conclusion

I'm not suggesting that Steve's point isn't valid - but he's done his readers a disservice by only presenting one side of the matter. Fortunately, the rest of the book (so far) is excellent and humbling - to such a degree that this minor quibble stuck out like a sore thumb. In a book which had more problems, I would probably barely have even noticed this one.

There's another possibility, of course - I could be competely wrong; maybe I've been approaching problems from a restrictive viewpoint all this time. How about you?

Macros, and languages within languages

skeet — Fri, 08 Feb 2008 23:31:32 GMT

Ian Griffiths mailed me about macros, and explained how LISP macros were very different to C/C++ macros, working at a language level instead of at a text level. I won't pretend to understand all about what would be possible and what wouldn't, but Ian gave a good example: query expressions in C# 3. Instead of being part of the language itself, they could apparently have been written as macros, if C# supported them. Then if you wanted to have similar support for different forms of expression, you could just write your own macro library.

Assuming that's what people are actually requesting, I can certainly see the attraction - but I'd still prefer it if C# didn't go down that route. I'll go back to C++ for the guts of the reason why, but it's not really about macros at this point. It's about building your own language. Once, someone told me that C++ wasn't a language - it was a meta-language; no-one used "bare" C++, they worked out their own language made from the building blocks of normal C++, and then used that.

That may or may not be true - or more likely, it's true in some places but not others - but it scares me as an idea. I'm not going to claim I know every nuance of C#, but it's pretty rare that you'd throw a line at me without it being reasonably clear what's going to happen and why, at the language level. Extension methods might mean a bit more information is required as to where a particular method comes from, but it doesn't take a lot of digging to see what's going on.

Now imagine that C# 3 didn't include query expressions, but that someone had come up with them as a macro library. It's not an insignificant amount of effort to learn what's going on there, and how it all maps to normal method calls, potentially with expression trees as arguments instead of delegates. Until you understand what's going on at a reasonably deep level, you can't really make any firm decisions as to what code including a query expression will do. (Heck, that's one of the premises of the book: you should really know this stuff, or at least be aware of it.)

That's fine when there's a single macro library used globally, but now imagine every company has their own - or worse still, has a bunch of them grabbed from Code Project, possibly including a load of bugs. Most of us aren't accomplished language designers, and I suspect there'd be an awful lot of macro libraries out there which weren't quite thought through enough - but were still useful enough to be attractive. They'd become magnets for code warts.

It's hard enough when you change company to work out what 3rd party libraries are in use, how they're being used, what the coding conventions are etc. It would be much worse if I had to learn another flavour of C# itself each time. I'm already worried that developers are picking up C# 3 without having a firm enough grasp of C# 2 - and that's when there's just a progression within a single language.

I know this all sounds patronising and/or elitest and/or "nanny state" applied to programming languages - but it's how I feel nonetheless. I just don't think we (as a development community) are mature enough to handle that sort of power without it turning into a blood bath. This sort of thing sounds fabulous for hobby and research development, and would probably be great in the hands of the best few companies in the world - but I don't think it's a good idea for the mainstream.

Okay - time to hear why I'm wrong :)

Java isn't an acronym

skeet — Mon, 17 Sep 2007 23:21:34 GMT

Just a quickie while I remember. A pet peeve of mine has surfaced again recently, while reading some CVs.

Java, the programming language, is just written "Java". It's not an acronym. There's no need to write it as "JAVA". That just looks shouty and somewhat silly. Why do so many people get it wrong? While we're at it, why does it irritate me so much to see it written the wrong way?

Why hasn't Microsoft bought JetBrains yet?

skeet — Fri, 01 Jun 2007 22:07:07 GMT

For those of you who aren't aware, JetBrains is the company behind IntelliJ IDEA, the Java IDE which I've heard amazing things about (I've tried it a couple of times but never got into it - I think I need an expert sitting beside me to point out the cool stuff as I go) and ReSharper, the incredibly useful (although somewhat resource hungry) add-in to Visual Studio that turns it into a respectable IDE.

What would happen if Microsoft bought JetBrains?

I'm sure that killing off the reportedly best Java IDE would do .NET no harm (even if it would be a fairly cruel thing to do, and still leave other perfectly good IDEs in the Java space), and surely they could use the ideas and experience of the company to improve Visual Studio significantly. I strongly suspect that tighter integration could make all the ReSharper goodness available with less performance overhead, and while it's no doubt too late now, wouldn't it have been wonderful for all of those features to be available in Orcas?

Anyway, just a thought.

Sheer Evil: Rethrowing exceptions in Java

skeet — Tue, 03 Apr 2007 20:07:00 GMT

This morning, I was looking through some code and I was annoyed (yet again) at Java's exception hierarchy, particularly when it comes to checked exceptions. Just as a reminder, everything that can be thrown in Java derives from Throwable. The predefined direct subclasses are Error and Exception. (You can derive from Throwable directly yourself, but I've never seen anyone do it, thank goodness.) Exception, and any class deriving from it, count as a checked exception - one that you have to declare if your method might throw it. Oh, except for RuntimeException, and its descendants such as NullPointerException. Blech.

This is really painful in some situations. In particular, the code I was looking at wanted to catch everything, act on it, and then rethrow it. My method was declared to throw IOException, and without the catch block everything compiled fine, so I knew that nothing I was calling should throw any checked exceptions other than IOException. However, rethrowing the exception is tricky - because the compiler doesn't know what you're up to. I ended up with this foul code:

try
{
    // Stuff here
}
catch (Throwable t)
{
    // Log the error (or whatever)
            
    // Now rethrow
    if (t instanceof IOException)
    {
        throw (IOException) t;
    }
    if (t instanceof RuntimeException)
    {
        throw (RuntimeException) t;
    }
    if (t instanceof Error)
    {
        throw (Error) t;
    }
    // Very unlikely to happen
    throw new RuntimeException(t);
}
finally
{
    // More stuff here
}

Nasty, isn't it? It would be lovely to somehow tell the compiler that you know there won't be any other kinds of checked exceptions thrown, just rethrow the original, it's all right guv, you can trust me, honest.

Well, apparently you can't really trust me. Not since the hack I worked out this morning. You see, exception checking only occurs at compile time. So, let's define a really harmless little class called ExceptionHelper:

public class ExceptionHelper
{
    /** Private constructor to prevent instantiation */
    private ExceptionHelper()
    {
    }
    
    public static void rethrow (Throwable t)
    {
    }
}

Nothing nasty going on, is there? So the compiler won't mind at all if I change the original code to:

try
{
    // Stuff here
}
catch (Throwable t)
{
    // Log the error (or whatever)
            
    // Now rethrow
    ExceptionHelper.rethrow(t);
}
finally
{
    // More stuff here
}

The only trouble is, it doesn't rethrow the exception any more, regardless of the name of the method. But as I suspect you've guessed by now, once we've satisfied the compiler, we can change ExceptionHelper.rethrow slightly:

public static void rethrow (Throwable t) throws Throwable
{
    throw t;
}

Recompile ExceptionHelper but not the calling code and we achieve exactly what we want - it will rethrow whatever exception we ask it to, and we've fooled the compiler into not worrying about the potential consequences. Of course, this means we could change the code in the try block to something which throws a completely different checked exception, and we'd never know until it happened - the compiler couldn't help us. The workaround for this is to temporarily remove the catch block and see whether or not the compiler complains.

I'm not actually suggesting anyone should do this, despite a certain appeal in terms of simpler, more readable code in the catch block. A hack like this is horrible, evil, awful. Which is why I had to share it, of course.

Wacky Ideas 3: Object life-cycle support

skeet — Wed, 28 Feb 2007 15:51:21 GMT

No, don't leave yet! This isn't another article about non-deterministic finalization, RAII etc. That's what we almost always think of when someone mentions the object life-cycle, but I'm actually interested in the other end of the cycle - the "near birth" end.

We often take it as read that when an object's constructor has completed successfully, the object should be ready to use. However, frameworks and technologies like Spring and XAML often make it easier to create an object and then populate it with dependencies, configuration etc. Yes, in some cases it's more appropriate to have a separate configuration class which is used for nothing but a bunch of properties, and then the configuration can be passed into the "real" constructor in one go, with none of the readability problems of constructors taking loads of parameters. It's all a bit unsatisfactory though.

What we most naturally want is to say, "Create me an empty X. Now configure it. Now use it." (Okay, and as an obligatory mention, potentially "Now make it clean up after itself.")

While configuring the object, we don't want to call any of the "real" methods which are likely to want to do things. We may want to be able to fetch some of the configuration back again, e.g. so that some values can be relative to others easily, but we don't want the main business to take place. Likewise, when we've finished configuring the object, we generally want to validate the configuration, and after that we don't want anyone to be able to change the configuration. Sometimes there's even a third phase, where we've cleaned up and want to still be able to get some calculated results (the byte array backing a MemoryStream, for instance) but not call any of the "main" methods any more.

I'd really like some platform support for this. None of it's actually that hard to do - just a case of keeping track of which phase you're in, and then adding a check to the start of each method. Wouldn't it be nicer to have it available as attributes though? Specify the "default phase" for any undecorated members, and specify which phases are valid for other members - so configuration setters would only be valid in the configuration phase, for instance. Another attribute could dictate the phase transition - so the ValidateAndInitialize method (or whatever you'd call it) would have an attribute stating that on successful completion (no exceptions thrown) the phase would move from "configure" to "use".

Here's a short code sample. The names and uses of the attributes could no doubt be improved, and if there were only a few phases which were actually useful, they could be named in an enum instead, which would be neat.

[Phased(defaultRequirement=2, initial=1)]
class Sample
{
    IAuthenticator authenticator;
    
    public IAuthenticator Authenticator
    {
        [Phase(1)]
        [Phase(2)]
        get
        {
            return authenticator;
        }
        [Phase(1)]
        set
        {
            authenticator = value;
        }
    }
    
    [Phase(1)]
    [PhaseTransition(2)]
    public void ValidateAndInitialize()
    {
        if (authenticator==null)
        {
            throw new InvalidConfigurationException("I need an authenticator");
        }
    }
    
    public void DoSomething()
    {
        // Use authenticator, assuming it's valid
    }
    
    public void DoSomethingElse()
    {
        // Use authenticator, assuming it's valid
    }
}

Hopefully it's obvious what you could and couldn't do at what point.

This looks to me like a clear example of where AOP should get involved. I believe that Anders isn't particularly keen on it, and when abused it's clearly nightmarish - but for certain comment things, it just makes life easier. The declarative nature of the above is simpler to read (IMO - particularly if names were used instead of numbers) than manually checking the state at the start of each method. I don't know if any AOP support is on the slate for Java 7 - I believe things have been made easier for AOP frameworks by Java 6, although I doubt that any target just Java 6 yet. We shall have to see.

One interesting question is whether you'd unit test that all the attributes were there appropriately. I guess it depends on the nature of the project, and just how thoroughly you want to unit test. It wouldn't add any coverage, and would be hard to exhaustively test in real life, but the tests would be proving something...

Wacky Ideas 2: Class interfaces

skeet — Wed, 28 Feb 2007 10:38:00 GMT

(Disclaimer: I'm 99% sure I've heard someone smarter than me talking about this before, so it's definitely not original. I thought it worth pursuing though.)

One of the things I love about Java and C# over C/C++ is the lack of .h files. Getting everything in the right place, only doing the right things in the right files, and coping with bits being included twice etc is a complete pain, particularly if you only do it every so often rather than it being part of your everyday life.

Unfortunately, as I've become more interface-based, I've often found myself doing effectively the same thing. Java and C# make life a lot easier than C in this respect, of course, but it still means duplicating the method signatures etc. Often there's only one implementation of the interface - or at least one initial implementation - but separating it out as an interface gives a warm fuzzy feeling and makes stubbing/mocking easier for testing.

So, the basic idea here is to extract an interface from a class definition. In the most basic form:

class interface Sample
{
    public void ThisIsPartOfTheInterface()
    {
    }
    
    public void SoIsThis()
    {
    }
    
    protected void NotIncluded()
    {
    }
    
    private void AlsoNotIncluded()
    {
    }
}

So the interface Sample just has ThisIsPartOfTheInterface and SoIsThis even though the class Sample has the extra methods.

Now, I can see a lot of cases where you would only want part of the public API of the class to contribute to the interface - particularly if you've got properties etc which are meant to be used from an Inversion of Control framework. This could either be done with cunning keyword use, or (to make fewer syntax changes) a new attribute could be introduced which could decorate each member you wanted to exclude (or possibly include, if you could make the default "exclude" with a class-level attribute).

So far, so good - but now we've got two types with the same name. What happens when the compiler runs across one of the types? Well, here's the list of uses I can think of, and what they should do:

Variable declaration: Use the interface
Construction: Sse the class
Array declaration/construction: Use the interface (I think)
typeof: Tricky. Not sure. (Note that in Java, we could use Sample.class and Sample.interface to differentiate.)
Type derivation: Not sure. Possibly make it explicit: "DerivedSample : class Sample" or "DerivedSample : interface Sample"
Generics: I think this would depend on the earlier "not sure" answers, and would almost certainly be complicated

As an example, the line of code "Sample x = new Sample();" would declare a variable x of the interface type, but create an instance of the concrete class to be its initial value.

So, it's not exactly straightforward. It would also violate .NET naming conventions. Would it be worth it, over just using an "Extract Interface" refactoring? My gut feeling is that there's something genuinely useful in here, but the complications do seem to overwhelm the advantages.

Perhaps the answer is not to try to have two types with the same name (which is where the complications arise) but to be able to explicitly say "I'm declaring interface ISample and implementing it in Sample" both within the same file. At that point it may be unintuitive to get to the declaration of ISample, and seeing just the members of it isn't straightforward either.

Is this a case where repeating yourself is fundamentally necessary, or is there yet another way of getting round things that I'm missing?

Wacky Ideas 1: Inheritance is dead, long live mix-ins!

skeet — Tue, 27 Feb 2007 20:46:00 GMT

(Warning: I've just looked up "mix-in" on Wikipedia and their definition isn't quite what I'm used to. Apologies if I'm using the wrong terminology. What I think of as a mix-in is a proxy object which is used to do a lot of the work the class doing the mixing says it does, but preferably with language/platform support.)

I've blogged before about my mixed feelings about inheritance. It's very useful at times, but the penalty is usually very high, and if you're going to write a class to be derived from, you need to think (and document) about an awful lot of things. So, how about this: we kill of inheritance, but make mix-ins really easy to write. Oh, and I'll assume good support for closures as well, as a lot can be done with the Strategy Pattern via closures which would otherwise often be done with inheritance.

So, let's make up some syntax, and start off with an example from the newsgroups. The poster wanted to derive from Dictionary<K,V> and override the Add method to do something else as well as the normal behaviour. Unfortunately, the Add method isn't virtual. One poster suggested hiding the Add method with a new one - a solution I don't like, because it's so easy for someone to break encapsulation by using an instance as a plain Dictionary<K,V>. I suggested re-implementing IDictionary<K,V>, having a private instance of Dictionary<K,V> and making each method just call the corresponding one on that, doing extra work where necessary.

Unfortunately, that's a bit ugly, and for interfaces with lots of methods it can get terribly tedious. Instead, suppose we could do this:

using System.Collections.Generic;

class FunkyDictionary<K,V> : IDictionary<K,V>
{
    IDictionary<K,V> proxyDictionary proxies IDictionary<K,V>;
    
    void IDictionary<K,V>.Add(K key, V value)    
    {
        // Do some other work here
        
        proxyDictionary.Add(key, value);
        
        // And possibly some other work here too
    }
}

Now, that's a bit simpler. To be honest, that kind of thing would cover most of what I use inheritance for. (Memo to self: write a tool which actually finds out how often I do use inheritance, and where, rather than relying on memory and gut feelings.) The equivalent of having an abstract base class and overriding a single method would be fine, with a bit of care. The abstract class could still exist and claim to implement the interface - you just implement the "missing" method in the class which proxies all the rest of the calls.

The reason it's important to have closures (or at least delegates with strong language support) is that sometimes you want a base class to be able to very deliberately call into the derived class, just for a few things. For those situations, delegates can be provided. It achieves the same kind of specialization as inheritance, but it makes it much clearer (in both the base class and the "derived" one) where the interactions are.

One point of interest is that without any inheritance, we lose the benefits of a single inheritance tree - unless object becomes a general "any reference", which is mostly what it's used for. Of course, there are a few methods on System.Object itself which we'd lose. Let's look at them. (Java equivalents aren't specified, but Java-only ones are):

ToString: Not often terribly useful unless it's been overridden anyway
GetHashCode/Equals: Over time I've been considering that it may have been a mistake to make these generally available anyway; when they're not overridden they tend to behave very differently to when they are. Wrapping the existing behaviour wouldn't be too hard when wanted, but otherwise make people use IEquatable<T> or the like
GetType: This is trickier. It's clearly a pretty fundamental kind of call which the CLR will have to deal with itself - would making it a static (natively implemented) method which took an object argument be much worse?
MemberwiseClone: This feels "systemy" in the same way as GetType. Could something be done such that you could only pass in "this"? Not a terribly easy one, unless I'm missing something.
finalize (Java): This could easily be handled in a different manner, similar to how .NET does.
wait/notify/notifyAll (Java): These should never have been methods on java.lang.Object in the first place. .NET is a bit better with the static methods on the Monitor class, but we should have specific classes to use for synchronization. Anyway, that's a matter I've ranted about elsewhere.

What are the performance penalties of all of this? No idea. Because we'd be using interfaces instead of concrete classes a lot of the time, there'd still be member lookup even if there aren't any virtual methods within the classes themselves. Somehow I don't think that performance will be the reason this idea is viewed as a non-starter!

Of course, all of this mix-in business relies on having an interface for everything you want to use polymorphically. That can be a bit of a pain, and it's the subject of the next article in this series.

What would make a good Java book?

skeet — Wed, 14 Feb 2007 20:25:03 GMT

So, Groovy in Action has been out for a little while, and I'm missing it - or rather, book writing. I'd like my next project to be a solo effort, almost certainly on Java. However, I'm interested in hearing what you good folks think would make a good Java book. I've got some ideas myself, but I'd rather hear unprejudiced opinions first. (I may be soliciting more feedback at a later date, of course.) So, shoot - what would you like me to write about?

Groovy 1.0 released

skeet — Wed, 03 Jan 2007 19:19:00 GMT

Groovy 1.0 has finally been released, and is available for download from the Groovy home page.

For those of you who didn't read my last blog post on it, Groovy is a dynamic language which runs on the Java platform and integrates very nicely with Java itself.

What I haven't advertised on this blog until now is that a month or so after starting with Groovy, I became involved in the Groovy in Action book. I won't claim that I wrote a lot of it - more polishing and adding some introductory material, really. I'm still extremely proud of it, however, and obviously I hope it'll sell bucket-loads.

So, if you haven't played with Groovy yet, now's a very good time to start: download it, have a bit of a play, and then buy the book!

Everything old is new again

skeet — Wed, 13 Dec 2006 23:46:10 GMT

I feel I'm too young to be making this kind of statement, but the sense of deja vu I get when reading about the layouts in WPF makes me nearly laugh out loud. Of all the things I can remember about Java 1.0 (this was before any number of things we take for granted now) I know that LayoutManagers exist - including the insanely hard to use GridBagLayout. Fortunately I learned over time that it wasn't always the most appropriate manager (far from it) but it was powerful.

Ever since I started using .NET I've been annoyed at WinForms' lack of layout management facilities. I'm pretty sure that when I complained about this to Chris Anderson once he said that it's all there really, but just not exposed very well. Hmm. I've tried and lost patience a few times - I suspect there are ways of sorting it all out, but it's not exactly straightforward.

Fortunately it all changes with WPF, which not only has various layout managers (not sure whether there's anything like Java 1.4's SpringLayout, which seemed useful last time I looked at it) but also makes them relatively easy to use with XAML. No more GridBagConstraints messes! Hurrah!

Anyway, it's good to see that .NET 3.0 has caught up with Java 1.0 :) (And no, I'm not under the impression that Java invented the concept of layout managers. It just happens to be the first environment I used them in.)