Skip to content
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

Open
gembin opened this issue Jan 23, 2014 · 4 comments
Open

Enhancement: add @Config and without extends Config interface? #66

gembin opened this issue Jan 23, 2014 · 4 comments

Comments

@gembin
Copy link

gembin commented Jan 23, 2014

add @Config annotation, without extends Config interface to have a more clean interface?

example:

@Config
public interface MyConfig{

    @DefaultValue("apple")
    String foo();

    @DefaultValue("pear")
    String bar();

    @DefaultValue("orange")
    String baz();

}
@lviggiano
Copy link
Collaborator

Not sure it is possible, but - in case - 👍

@lviggiano
Copy link
Collaborator

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.

class diagram

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 Config super-interface.

@gembin
Copy link
Author

gembin commented Jan 28, 2014

There is no good reason, but here are some points.

Before java 5, Marker Interfaces were the only way to declare metadata about a class, and with java 5, they can be completely replaced by Annotations, which allow for a very flexible metadata capability.

and for the sub-interfaces Reloadable, Mutable, and Accessible, although they are not Marker Interfaces, however, they can be also replaced by Annotations.

Suppose i defined a config API which based on owner , i certainly don't want expose the internals to end user. The internals means the methods defined in those sub-interfaces. Especially some are designed for debugging.

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:
Take Mutable as example, i would prefer strong typed to the string based: String setProperty(String key, String value);, some pseudo codes:

@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();

@lviggiano
Copy link
Collaborator

Interesting points. I'll consider all these suggestions for future
versions.
Thanks.

L.
Il 28/gen/2014 15:10 "Bin Zhang" [email protected] ha scritto:

There is no good reason, but here are some points.

Before java 5, Marker Interfaces were the only way to declare metadata
about a class, and with java 5, they can be completely replaced by
Annotations, which allow for a very flexible metadata capability.

and for the sub-interfaces Reloadable, Mutable, and Accessible, although
they are not Marker Interfaces, however, they can be also replaced by
Annotations.

Suppose i defined a config API which based on owner , i certainly don't
want expose the internals to end user. The internals means the methods
defined in those sub-interfaces. Especially some are designed for debugging.

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:
Take Mutable as example, i would prefer strong typed to the string based: String
setProperty(String key, String value);, some pseudo codes:

@Mutablepublic interface MyMutableConfig extends MyConfig{
//setters
MyMutableConfig foo(String value);

MyMutableConfig bar(String value);

MyMutableConfig baz(String value);}

Operation op=configEditor.edit(MyMutableConfig.class);//begin editMyMutableConfig config=op.begin();
config.foo("foo1").bar("bar1").baz('baz1');
//finished editMyConfig updatedConfig=op.end();


Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-33480867
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants