Well the issue is not plugability as much as how plugability is implemented. Certainly the Class.forName() way is a bit of a hack, even if it convenient sometimes.
On Sun, 14 May 2000, Brandon wrote: > > Perhaps this suggests an alternative approach might be appropriate for > > the loading of different types of Address and Connection. It is not > > like we add new types with sufficient frequency to justify this "plugin" > > capability. > > I prefer pluggability. I think pluggability doesn't need to be justified > so much as taking it away (or not putting it in) needs to be justified. I > don't think all related classes need to be in the same package. It's > certainly a good thing to do, but in this case I think it's okay if some > classes are split up over two packages. Or, if not, then the testbed > packages should be moved into the same package as the tbConnection, > etc. classes. This would currently be the Freenet package. I think it > would be nice to move the Connection classes one package per protocol. > > So Freenet.protocols.tcp, Freenet.protocols.tb, etc.. > > Although protocols might not be the best name. > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- ___ Oskar Sandberg md98-osa at nada.kth.se _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
