More Great Things about Retlang

I’ve lost count of the number of times I’ve seen a technology that looked great in the sample, but didn’t hold up when I took it for a proper test drive.  Mike Rettig, on the other hand, has really thought through the use cases.  So when you try to take a sample program and hit the real world, you discover he’s been there before you.  Here’s some highlights:

• Everything implements interfaces.  You can mock or stub pretty much everything.  (You might want to create your own abstract factory, though.)
• Not only does everything have an interface, the interfaces are finely grained, making stubbing even easier.  You don’t need to simulate channel subscription if you only use channel publishing, for instance.
• The publish/subscribe model is very robust
  • You can send a single message to multiple listeners
  • You can handle a message synchronously on the sending thread (providing you’re careful about thread-safety)
  • You can batch the processing of messages, allowing you to ignore duplicates.
• You can set up timed events, one-shot or repeating.  This is pretty vital to allow long-running services to report their state and perform periodic clean-ups.
• It’s really fast.  If you’ve got a performance problem, I can assure you it’s your problem, not Retlang’s.
• You can inject your own behaviours nearly everywhere.  For example, you can set up a common error trap and logging using ICommandExecutor.
• A single queue can hold lots of different messages.  This is vital for complex interactions.

While I’m here, a couple of things I don’t like:

• It would be nice if there was an interface that incorporate ICommandQueue and ICommandTimer.
• Equally, I’d rather like IQueueChannel to implement IChannelPublisher.
• The default command executor kills the thread if an action throws an exception.  This is a pretty aggressive default behaviour.

You’ll gather that these are pretty minor quibbles about an excellent library.