> > 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...
I certainly agree. When have I every said otherwise? I'm the one here arguing as hard as I can to keep Freenet simple--limiting message types, searching, and other stuff we don't need. The few things I've suggested adding like key types I've listed concrete applications for. I'll probably lose the searching argument, and I can live with that. But I think this one's important. > 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. Well that's one way to look at it, but I'm just saying that it's more useful and flexible to look at it differently--sure, you _can_ use message types for that purpose, but that doesn't mean you should. Yes, "ugly" is subjective, but it's quicker to type than "contrary to my instincts as a programmer with 20 years experience". And anyway Oskar and I have given several good, solid, detailed reasons why it's a bad idea. Any way you want to write code is fine with me--but messing with the protocol itself affects everything. It's important to get that right, because you can never go back. I've done protocols. I know protocols. > 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. I admit that I'm not sure whether they will be or not--I gave examples, and Oskar gave his reasons, but I'm mostly just arguing from instinct. A Keytype field is another way to go. Neither that nor my suggestion of subclassing the SearchKey field raises any hackles for me, but I thik subclassing SearchKey _is_ the right place to subclass here. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
