Hi Peter,

Unifying these seems like a good idea! Uri should be fine for basic usage - merge my developers/peter/calitko-petr branch into to get the code. I see that Http::ClientSession uses QUrl. I don’t think ClientSession has been tested much - it should better be ported to Protocols/Http. The good thing with Mock Objects is that you can test a class that is supposed to use ClientSession even if ClientSession does not exits. More to that in a while.

I’ve started unifying URL storage in BitTorrent classes - I’ve already changed Torrent[Parser] class (thanks for fixing the URL validation in the TorrentParser! I don’t know what I thinking when I was writing it..). I’ll soon rewrite the TrackerRequestWriter class and then I’m going to work on the TrackerRequestSession. But first I’m going to check your GenericSession/Data classes docs - looking forward to that :)!

TrackerRequestSession hints [snip]

Thanks a lot for these comments! I’m going to realize it as soon as I’m done with the TrackerRequestWriter.

I’ve had the same problem with dtors… I asked a friend of mine who’s using EasyMocks in Java how they’ve solved the problem there and he told me “There’re no destructors in Java.” and I thought “Wow!” :-)

Yes, that surprised me too when I was writing some simple Java code for my friend :). It’s because that Java is using an automatic memory management via GC and the only way how to possibly free some resources is to use a special finalizer method, which can be considered as a “destructor”, but there are some issues with that (for example you don’t know when exactly it will be called - you can of course force it’s call manually but that seems a little bit unnatural for me). Python doesn’t have destructors either - though there is a special member function called __del__ which is pretty much the same as Java’s finalizers, but honestly, I haven’t used it yet.

I think that it should be safe to call the dtor from any situation - especially as part of stack unwinding when an exception is thrown. Thus, it might be good not to call any extra functions. So instead of the dtor of TrackerRequestSession calling abort() on HttpRequestSession, the dtor of the latter would call its private abort() equivalent (no status notifications though!) to clean up stuff before the object is actually deleted.

Ok, I agree - I’ll do it that way and I won’t call status functions.

I think I would never have created a private static function but thanks to you I got an insight when I should :-). It’s the semantics that const and static communicate. A const function would not modify the state of the object but would need access to the members, whereas a static function doesn’t need to access the member variables, so it is essentially a kind of “generic” helper - a function that could just as well be declared static in the cpp file.

Looking at private const functions in Uri, I think that the functions doEncode, shouldEncode, hex, quoted, doDecode, fromHex, unqoted, ensureNotNull all better be static rather then const! What do you think?

Yes, exactly - when I’m deciding whether to declare a function const or static, I think whether it would need access to it’s private data/functions and if not, I can declare it static.

As for the private functions in Uri, I agree to make these static rather than const!

Have a nice day,

Petr