Don't you just hate when you have to remember how to use std::string to do any intricate string manipulation in C++, or trying to remember the correct stringstream class names to convert your measly collection of objects to their bloody string representation.

Wouldn't it be nice if there was an almost pythonic way to do it?

Well - ok! Besides using python then? Ok, maybe there is not such a thing (yet!), but until then you can hopefully make a fragment of that dream come true with "yet another string class" from my hand. Built over the years and with documentation and lots of test cases.

Bugs and improvements are very welcome, it's BSD'ed so nothing should keep you from using it in all your projects in the future - i will certainly be using it everywhere now.

Oh, and it's called hstring and there is more stuff on that page (e.g. documentation).

Finally i have some nice summer reading for you while i spend the next week in spain, INTERCAL, the inside story - hilarious!

P.S. The post of hstring (which has been long due) might be inspired by a friend of mine calling me a C# fanboy, you know who you are ;-)

In the C++ world we are only used to one way of implementing an interface in a class, but in C# you have two options: either an implicit implementation, like the one in C++, or an explicit interface implementation.

Consider the following code:

   public interface ITest
   {
      void DoStuff();
   }

   public class Test : ITest
   {
      /// Explicitly implement an interface

      void ITest.DoStuff()
      {
         System.Diagnostics.Debug.WriteLine( "Test is doing stuff" );
      }
   }

In the code above we define an interface with a method called DoMethod which is implemented by the class Test. The cool thing is that we now have associated a method implementation explicitly with a method on an interface, first and foremost this means that we do not have to mark the visibility of the method (public, protected, etc.). Additionally it also means that if the method declaration in the interface is modified in some way, e.g. if a parameter is added or removed, we will get a compile error saying the our implementation of DoStuff does not match the one in the interface, with implicit interface implementation we are only told that Test does not implement the new DoStuff method.

Where it gets really cool is when you consider what happens if a method is removed from the interface, this shows up as a compilation error when we use explicit interface implementations, where as with implicit interface implementations the method can linger around in a class for a long time, before it is noticed as implementing a method of a previous interface revision.

   public interface ITest
   {
   }

   public class Test : ITest
   {
      /// Compilation error, no method DoStuff on ITest interface

      void ITest.DoStuff()
      {
         System.Diagnostics.Debug.WriteLine( "Test is doing stuff" );
      }
   }

So far this is a really cool thing, I like things that are checked at compile-time, and I especially like any technology that can help implement interfaces and keep interface implementations in sync with interface definitions.

But, and this is a big but, when you start using a class which implements an interface explicitly you are left with one big thorn in your eye, you would think that writing something like the following should be possible:

   class Program
   {
      static void Main( string[] args )
      {
         Test test = new Test();
         test.DoStuff();
      }
   }

But what are we faced with? Compile errors! The compiler claims that Test does not contain a definition of a DoStuff method. This is really contrary to the common belief that when you implement an interface in a class, you can call those methods on instances of that particular class directly. In this case you first need to cast test to ITest to be able to call the method.

Even more horribly, this means that how you implement an interface in a class, implicitly or explicitly, changes how that class can be used - this is the one that really baffles me - it seems like complete abandonment of good clean object oriented design.

Now, I think I understand why this was done, the whole reason for allowing for explicit interface implementation is probably to make it possible to distinguish implementations of similarly named methods in separate interfaces, e.g. ITest.DoMethod() and ISecondTest.DoMethod(). But I find it strange that mr. Hejlsberg have overlooked the advantages of explicit interface implementations.

For a long time i have been wanting to do some posts on things i like or dislike about C# and the whole .net thingy, and since i'm using it everyday at work there is a remote possibility that i will hit on something interesting.

The first thing i will cover is the yield keyword. For python developers this is all old hat, but for C# developers it is a great improvement to the language.

Basically it rids you of implementing all sorts of "crazy" iterators to supply a generic interface to collections of internal data that you wish to expose.

Normally you try to write generic code, and make your objects as loosely coupled as makes sense, this introduces a problem when you are working with internal collections of objects.

For instance, consider a Department containing a collection of Student(s) - in the first implementation this could be implemented as a simple vector of Student(s) (a List in .net), and you might expose the internal data structure by providing a Students property like the following:

   IList<Student> Students
   {
      get
      {
         return m_students;
      }
   }

Ok, so far so good, the users of the Department class can now see which students belong to a particular Department, but the users of the class can still modify the collection, they believe they can index the list by integer index, and so on, and so on, the IList<> interface is _very_ broad. You could expose it as an ICollection<> but that would still expose the collection. What you really should do, is have the Students property return an IEnumerable<Student> instance.

This will make the internal way that a Department class represents students completely independent of the way users of the class access them. Luckily List<Student> already exposes the IEnumerable<> interface - so, easy!

   IEnumerable<Student> Students
   {
      get
      {
         return m_students;
      }
   }

What happens now is that someone comes along and says - hey! Finding out whether or not a student is in a particular Department just by traversing a list is too slow! So you decide to go with something like a Dictionary mapping from student id (SSN or something similar) to the Student object. But you still want users to be able to, simply, traverse the list of students. With a Dictionary that is not so easy, even though a Dictionary exposes the IEnumerable<> it does so for a special Dictionary.KeyValuePair type - which is no good for our purpose. This is where yield will help us for the first time - check out how i implement an IEnumerable<Student> class in 5 lines:

   IEnumerable<Student> Students
   {
      get
      {
         foreach ( KeyValuePair<int, Student> pair in m_students )
         {
            yield return pair.Value;
         }
      }
   }

Isn't that just almost pythonic'ly beautiful? Isn't that just the simplest way possible to implement that particular task?

--

An even nicer example.

Where it will really save your ass is if you need to traverse a tree structure sequentially, then you just yield your way on to beatiful code - no more note keeping while trying to traverse the tree correctly. Just implement something simple like the following:

class TreeNode
{
    List<TreeNode> m_children;
    ...
    IEnumerable<TreeNode> AllChildren
    {
        get
        {
            foreach ( TreeNode child in m_children )
            {
                yield return child;
                foreach ( TreeNode subChild in child.AllChildren )
                {
                    yield return subChild;
                }
            }
        }
    }
}

This is pretty much as simple as you are going to get, of course it would be nice with support for a call to yield to automatically yield every member of another IEnumerable<> object, such that the innermost foreach could be replaced with a simple yield child.AllChildren;. That would be _really_ awesome. Does anybody know where to report enhancements (and bugs for that matter) to mirosoft?

You still have the same cross-thread issues as with List<> and Dictionary<>'s implementations of IEnumerator<> but hey, you can't have it all!

Cheers!

-- A microsoft fanboy!

P.S. I haven't even scrached the surface of what the yield keyword can do for you - there is no requirement that you can only expose data throught yield, how about an implementation of python's xrange(from,to,increment) in C#:

   IEnumerable<int> Range(int _from, int _to, int _increment)
   {
      for ( int i = _from; i < _to, i += _increment ) return yield i;
   }

Strangely pleasing! (bonus points for writing a generic version)

Or perhaps a way to filter the output:

   IEnumerable<Student> Seniors
   {
      get
      {
         foreach ( Student student in m_students )
         {
            if ( student.TimeOnCampus > 3 ) yield return student;
         }
      }
   }

Which of course is horribly specific, why not generic' it up a bit:

   IEnumerable<Student> FilterStudents ( Predicate<Student> _filter )
   {
      foreach ( Student student in m_students )
      {
         if ( _filter(student) ) yield return student;
      }
   }

Not hard to see why lambda expressions is part of the new C#, and LINQ also seems closely related to this.

It's not python, but it's is pretty close for a statically linked language without template (as in C++) support.

Hey, i actually said something positive about something microsoft did! I _must_ be getting old, maybe i should pick up smoking again.

I finally found a bit of time to hack a bit on the evolution spambayes plugin, and there is now a version 0.1.6 ready, which works with Evolution 2.12.

Hopefully this will hopefully make Tom Arnold and Jim Rorie happy, or at least give them a reason to try _yet again_ to see if they can get it to work.

There is a new package in my DebianRepository for those fortunate enough to be running Debian (should also work on Ubuntu).

I am not reporting anything on company wise so far, other than: We're working on it!

Ok, this time i actually have something to tell.

I've quit my job!

Oh yeah, scary stuff!

I have a former colleague who have been working on a project that he has been wanting do to for a long time, actually he has worked for a long time on the project and he is now ready to make the jump to "hey look at me! i'm a company".

Well since he is going to start a company he, of course, need employees, and guess what, i am the first one!

So from January the first (preferably the second to avoid too many hangovers) i am going full-time with Sequanto.

We will start with focusing on creating the best damn system testing tool on the face of this planet (and maybe others), we are both tool-guys so there should plenty of opportunity for making a terrific tool.

This might mean that this blog will be focusing more on testing, but i am sure that you can live with that, _any_ focus is probably a good thing at this point.

Oh, and merry christmas to those celebrating it.

(And if you need some testing software for embedded devices or otherwise, don't hesitate to write me)