> Lack of imagination is a really BAD reason to do anything. Because you never know, someday you might possibly want to do something even though no one can think of what that might be so let's go ahead and add something just in case is also a bad reason to do anything. Every abstraction should be there because it adds something that someone might conceivably want for some reason. A favorite pasttime here is to argue that we must do things a certain way because what if someone wants to <insert absurd thing no one would want>.
> Sorry, but not painting yourself into a corner wins hands down > over "elegant" any day; especially since "elegant" is in the eye > of the beholder. If you ask me, adding message types for this > is ugly and overly complex. Keytypes are not even conceptually > message types--why you insist on confusing the two baffles me. > Even if it happens to make the code a little shorter or simpler, > that's STILL no excuse for this fundamental design mistake. Ugly and overly complex are also subjective values. As I conceive of key types they _are_ conceptually message types. When you subclass a message, it must mean _something_. The subclassed message must be adding some sort of behaviour. The only behaviour we ever talk about adding are support for different key types. This is assuming that the subclassing of messages is there for a reason and useful. If we're just splitting messageType into two fields where the new messageType holds the first level (Request.Data) and the rest is in KeyType (ContentHash.SHA1) Then this whole discussion is just a matter of the field naming convention. It's only really meaningful if the message type inheritance is going to be used for something else. Otherwise we're just adding a second layer which will duplicate things which the first layer already does. But if you think messages are going to be subclassed for purposes other than to support different key types then I'm all for key handler classes if they're implemented with a KeyType field. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
