I’m testing UI again, and I guess that it is going to suck this time as it did before. This time I’m using Netron for the graphs, and it’s not that bad this time, mainly because I can get into the guts of Netron and change it, and this make all the difference in the world.

The problem with that is that while Netron is a library for graphs, it is mainly for painting graphs, so it got a boat load of baggage that I don’t need when I’m doing testing. I started using the Pass Null pattern, but there seems to be lot of stuff that just can’t accept null (and doesn’t check for it).

I didn’t look too deeply into the way Netron is structure, I admit, mainly because there is quite a bit of GDI stuff that I just don’t want to get into, but I guess that I’ll have to, at least to rip out the parts that I’m not using and don’t want to maintain. The main problem I’ve with Netron is that it needs to keep a lot of state, which makes life hard when you try to understand what is going on around you. The framework is there to help you build really complex stuff, but I managed to scale it down without much trouble.

I just realize that I can just use the whole thing for testing without bother the UI bits. This mean deleting my façade code (always a pleasure) and using the real thing, and it doesn’t affect the way I’m working with the model.

All things aside, Netron looks really good, check out the sample applications screenshots. I managed to get a working sample that looked about as good as Microsoft’ Class Designer in no time, and Netron takes care of most of the details with regard to object movement, highlighting, connecting the dots, etc.

Can someone justify when I get those types in the System namespace? (from the System assembly)

• NewsStyleUriParser  
• GopherStyleUriParser
• Etc..

I mean, I get that networking is important but isn’t putting NNTP and Gopher(??) in the System namespace too much?

There are way too many places in the class library that are internal without cause. The entire ASP.Net caching system is one big internal block, and the Compression namespace has only two public members.

I need to read just the header of a zip file, as far as I can see, this is certainly possible using the classes in the framework, but they are all marked internal, so I have no way in short of using Reflection.

I get the issues with the testing matrix, and the possible backward compatibility issues that may happen when developers use stuff that you may want to use. But the documentation contains quite a bit of classes where the only documentation is “This class is for the framework internal use only” which should be warning enough for developers that they may change without warning.

I had a change today to look at the implementation of both classes, and I really don’t get what went through the minds of the developers in Microsoft when they wrote this class.

To be (brutally) short, GZip is a derivative of the Deflate algorithm with some additional headers tucks on it. This seems like an ideal case for inheritance, put the Deflate algorithm in its own class, and then put the GZip handling in a derived class.

On the surface, this is what both Microsoft and #ZipLib did, but I took a look inside today with Reflector and found that System.IO.Compression.GZipStream is nothing but an empty shell around DeflateStream. I mostly expected that, but I was very surprised to see that no where in GZipStream there was handling of the  GZip headers.

Looking a little deeper, I found this constructor:

internal DeflateStream(Stream stream, CompressionMode mode, bool leaveOpen, bool usingGZip)

It makes the OO developer in me cringe in pain. Why would they do that? This means that the DeflateStream needs to knows about its children, that it has specialized behavior for one specific child, etc. This is just wrong.

The #ZipLib got classes that actually have behavior, by the way. That is, the child class extend the functionality of the base class. This sounds familiar, I wonder where I heard those before…