+1 to autoloading with finer-grained control.
Robert Zeigler skrev:
Howard Lewis Ship wrote:
I've been giving this a bit of thought lately.
It seems to me that a likely scenario is one in which an existing
library, such as tapestry-hibernate, doesn't do quite what a user
needs, but contains a lot of useful code that could be resused.
However, autoloading means that just having the JAR on the classpath
wires it up, without giving an option to use the code but not the
services.
In addition, another common case is to forget to add a module's JAR to
the classpath, and then not understand why things are not working.
The solution to both of these problems is to be more explicit about
bringing in modules. The approach I'm moving towards is to add a
@SubModule annotation to the application's module. With that in place,
a missing dependency is a compile time error.
Thoughts?
I think autoloading has a lot of merits, and would hate to see it ripped
out. What I /would/ like to see is finer-grained control over
autoloading. For example, a mechanism to specify which modules should
/not/ be autoloaded.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
