Sharp wishes: nameof

Hi again, after over half a year of silence i think i am finally ready to write something again. The thing is: i have been writing a lot of C# lately as part of my job.

When you work some years with a language you start to envision certain improvements to the langauge which would make your life much easier. I plan to write these findings here as i find the time to do so.

The first thing i wish to tackle is the "lack of" a nameof operator, this is actually something which is lacking in Java and C++ too, but i find that it is more needed in C# because you deal with a lot of strings there, not to say that it would not be a huge boon in any language.

What this new operator tries to tackle is a problem most C# developers have faced: you have a class with a number of properties, these properties can be updated which, in turn, makes the object instance emit a PropertyChanged event for that particular property.

The problem comes when you want to write code which reacts to this property change for a particular property:

1
2
3
4
5
6
7
8
9

  ...
  private void object_PropertyChanged ( object sender, PropertyChangedEventArgs args )
  {
     if ( args.PropertyName == "NumberOfSamples" )
     {
        // Do stuff
     }
  }
  ...

This works ok at the beginning, but you are actually introducing dynamic/runtime programming into your statically compiled program. What happens if NumberOfSamples changes name to NumberOfActualSamples ? Your code will be broken but you will not see it on compile time, only on runtime.

Sometimes people, including myself, handle this by introducing an inner public class called Properties which contain several public const strings with the property names:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class MyClass
{
   public class Properties
   {
      public const string NumberOfSamples = "NumberOfActualSamples";
   }

   private int m_numberOfSamples;
   public int NumberOfSamples
   {
      get
      {
         return m_numberOfSamples;
      }
      set
      {
         if ( m_numberOfSamples != value )
         {
            m_numberOfSamples = value;

            OnPropertyChanged ( Properties.NumberOfSamples );
         }
      }
   }
}

This is actually quite a nice way to write code, you even get the added benefit of being able to search your code for places where a particular property is used from inside visual studio by using the built-in "Find all references" command.

But please notice that this is a violation of the DRY (Don't Repeayt Yourself) principle, that all hackers hold so dear.

A further complication is that this does not work for interfaces where inner classes are not allowed.

So what to do?

My proposal is to add a "nameof" operator, which takes the name of an identifier and returns it's name as a string. The "OnPropertyChanged" part of the code above would then look like:

1
2
3

...
OnPropertyChanged ( nameof(NumberOfSamples) );
...

This syntax looks pretty easy to me, nameof works pretty much the same as typeof.

Of course you would have to make a few adjustments to be able to do things like:

• Getting the complete name of an identifier (MyClass.NumberOfSamples), maybe something like fullnameof(...) could be introduced.
• Complete name including namespace, not sure what this operator should be called, suggestions?

I am sure you can think of more.

This is just a proposal, please report back with comments.

0 Comments

For a long time my primary animosity against windows has been the lack of a standard packaging system like on Linux, where keeping your system up to date is a simple process that does not require you to run 10 different programs with 10 different interfaces and rebooting 10 times.

In the past this has made my blood boil several times, two years ago it even got so bad i had to blog about it

Several months ago i created a program that will hopefully make this less painful in the future, and now i think it is time to tell the world.

You might have noticed the Vaca link on the top of this page which has been here for some months now too, it will lead you to my "repository" of Vaca sources.

Ok, let's back down a bit, what exactly is Vaca?

Well it is a simple "download and install program" which uses rss feeds to query when programs come in new versions. It simply downloads the newest version of a program's installer and executes it with the proper parameters to install without bothering you with the "next,next,next,next,finish" nonsense.

The reason for using Vaca is "obviously" to make it even easier for projects and bloggers to publish new versions of their software, they simple slap a vaca tag in their rss feed and Vaca will eat it all up.

Now, back to the Vaca link at the top of this page. It will lead you to a repository i keep of Vaca rss feeds (called sources). This is more a proof of concept than anything else, if Vaca takes off i know that i wont be happy with maintaining a list of thousands of software up-to-date. I don't scale well :)

I think that is enough talk, give it a whirl and tell me what you think. And if you start publishing any Vaca sources, incorporate Vaca in your product (please do!) or some other cool thing, please let me know!

If this gets enough leverage i will have to set up a bigger Vaca source site somewhere where admins will be able to edit the site without me having to be the weak link.

Happy Hacking!

0 Comments

Today i found the time to create a small utility i have been needing for some time.

A little background:

I use emacs's rcirc client to talk on irc and on Debian i use the libnotify library's notify-send command to notify me when someone talks to me, as described here.

So now i have created a windows utility to do this: WinNotify which is just a simple command line utility to make windows popup one of those balloon notification dealies.

I am sure it can be applied to other things - please do!

0 Comments

I have played a bit with bzrweb to get it working with mod_python, this was fruitful and you can now browse some code at http://halfdans.net/bzrweb/

Playing with that also got me into working with bzrlib, the python library behind the Bazaar revision control system. To try that out i got bazaar into my "wiki/blog" system and i can now put some commit logging on the pages.

So you should see a list of the latest commits for halfdans.net on the right.

0 Comments

After much toil and trouble with Django bugs #8630 and #9303 i finally have a comment system with email verification up and running.

It got kinda late before i got the whole thing working so i do not know how robust the code is. As always you are welcome to report any problems and security holes to me (my email is at the Colophon page).

I also got rss working, almost a painless introduction, the Django guys really knows what they are doing - although as you can see from the above bugs, perfect magic can be hard to create.

0 Comments

I have released a new version of Vertigo with the changes required to make proxy http work, and hence, make halfdans.net run with Django.

I have also finished migrating the old Trac site to halfdans.net, it is not as fancy and bug tracking is going to be a bitch - but since i'm running on Django i can add some functionality to cope with it when the need arise.

The DebianRepository and BazaarRepository has also migrated to halfdans.net, so update your /etc/apt/sources.list and friends to follow along.

Thanks to the davfs2 guys i now have my repositories mounted locally on my laptop and i can use all my normal tools to access the files as if they were local on my machine.

When will microsoft add a new webdav client to windows? (Nautilus could also use a more robust one but it serves it purpose most of the time).

1 Comments

I have found a few hours lately to convert halfdans.net to a Django application - and it is now done - more or less at least, the comment posting system still needs to be modfied a bit.

I am using the comment system that comes with Django by default (thanks to the included batteries) and there is not built-in support for "email confirmation" which is something i really need to do avoid having to monitor new comments for spam all the time.

Ok, first order of business, i am abandoning further work on my EvolutionSpamBayesPlugin i have been running with the bogofilter plugin and it seems to work quite well. Just remember to train one message as ham to make it "go".

0 Comments

This weekend i suddenly found the determinism to start tackling something i have been wanting to do for a while: transition halfdans.net to Django.

This has several implications, first of, i want it to run as a separate user to ensure security. Hey, one persons paranoia is another persons security consience. I could run it on the http://dev.infonet.dk server, but that one is going away some time in the future since we are eliminating that server in favor of just having a simple router do the job. The http://laesehesten-randers.dk server will also be upgraded some time in the future, it runs very hot - usually crashes during backup - not a great place to crash!

So, the option i have is, e.g., to run another apache instance on an alternate port, this is certainly one way to go ... buuuut, i really think a thing like this is better done using a virtual server. And it gives me a nice chance to take a look at one of the many virtualization options availble for debian, to make a long story short i settled on user-mode-linux since that just seemed like a nice way to go - and didn't require any host kernel meddling - and truth betold i didn't take the time to research other options at all.

I will write up on my user-mode-linux experience later.

One thing that needed doing before halfdans.net can start to migrate to Django is to get Vertigo to support proxying request to another server, this is pretty simple using Apache but i, of course, wanted to automate the process such that it is easy to do again and again.

Vertigo used to use Apache 1.3, but that version does not have mod_proxy support on etch, so i needed to migrate Vertigo to Apache 2.0 (2.2 actually), so now we have release 0.6.4.1 which requires Apache 2.0 and supports proxy subdomains.

I also found another rather embarrassing bug in Vertigo which should definaetely make you upgrade if you are using Vertigo (i am pretty sure i am the only user at the moment).

Since the server halfdans.net is hosted on has a tendency to run hot and crash, the virtual server is not running at the moment, but when it is it will be available at http://test.halfdans.net/

That is all for now, hope you all remembered George the past saturday, i guess all things really must pass.

0 Comments

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 ;-)

0 Comments

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

   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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

   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:

1
2
3
4
5
6
7
8

   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.

2 Comments