-
-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: add @Config and without extends Config interface? #66
Comments
Not sure it is possible, but - in case - 👍 |
By the way, is there a good reason on why one should not want to extend an interface? At the moment Config is a "marker" interface, but there are sub-interfaces extending from Config, that are actually defining more things. Extending an interface does not actually imply any particular limitation, since Java have multiple interfaces implementations. Those interfaces are not meant to be implemented by Java classes, but being generated by dynamic proxy. So I can't see what's the benefit of removing the mandatory |
There is no good reason, but here are some points. Before java 5, and for the sub-interfaces Suppose i defined a config API which based on i.e. public interface Accessible {
/**
* Prints this property list out to the specified output stream. This method is useful for debugging.
*
* @param out an output stream.
* @throws ClassCastException if any key in this property list is not a string.
* @see java.util.Properties#list(java.io.PrintStream)
* @since 1.0.4
*/
void list(PrintStream out);
/**
* Prints this property list out to the specified output stream. This method is useful for debugging.
*
* @param out an output stream.
* @throws ClassCastException if any key in this property list is not a string.
* @see java.util.Properties#list(java.io.PrintWriter)
* @since 1.0.4
*/
void list(PrintWriter out);
} Some rough ideas: @Mutable
public interface MyMutableConfig extends MyConfig{
//setters
MyMutableConfig foo(String value);
MyMutableConfig bar(String value);
MyMutableConfig baz(String value);
}
Operation op=configEditor.edit(MyMutableConfig.class);
//begin edit
MyMutableConfig config=op.begin();
config.foo("foo1").bar("bar1").baz('baz1');
//finished edit
MyConfig updatedConfig=op.end(); |
Interesting points. I'll consider all these suggestions for future L.
|
add
@Config
annotation, without extendsConfig
interface to have a more clean interface?example:
The text was updated successfully, but these errors were encountered: