From the Map perspective it may not be better. But from the perspective of abstracting how individual Plugins are created it probably is better. Remember, this is for allowing some sort of programmatic configuration, such as a configuration file written in Groovy. I find the idea of that kind of configuration actually creating Appenders, Layouts, etc, directly very scary.
Ralph On Jun 16, 2014, at 8:36 AM, Remko Popma <[email protected]> wrote: > > > On Tuesday, June 17, 2014, Ralph Goers <[email protected]> wrote: > Yes, for a programmatic configuration builders would be better. Unless, of > course, we came up with some other way for programmatic configurations to > interact with plugins. For example, a method like > > T createPlugin(PluginType type, Map<String, Object> map) > > might make more sense. Then it wouldn’t much matter whether we are using > builders or the factory pattern. > > Is that really better? Personally I try to avoid map-like APIs as it puts the > burden on the user to know what keys to use and what value types are > acceptable. > > Plus you lose the compiler-check benefits of the factory pattern. > > Ralph > > On Jun 16, 2014, at 8:12 AM, Matt Sicker <[email protected]> wrote: > >> Programmatic configuration is feature in that list of issues Ralph >> mentioned. I don't see any good way to do that without using the fluent >> builder pattern as that's how programmatic configuration APIs are usually >> done. The other ways are usually things like closures/lambdas, but that >> would require Java 1.8+ to work. Groovy supports closures which is what >> makes Gradle so much less verbose, so that, too, is an alternative way to >> support builders. >> >> I guess the important thing to consider here is that the builders aren't for >> _plugins_, but are for plugin _configurations_. That makes me think that the >> factory methods (whether they be private or public) should be far more >> generic such as accepting a PluginConfiguration object (each specific to the >> plugin) or a generic Map<String, Object> that also makes it a lot simpler to >> pass in plugin attributes. >> >> >> On 16 June 2014 10:05, Gary Gregory <[email protected]> wrote: >> Right, so they are not part of the public API, unless we consider >> programmatic configuration (not from a file). >> >> Gary >> >> >> On Mon, Jun 16, 2014 at 10:56 AM, Remko Popma <[email protected]> wrote: >> Paul this is about the plugin factory methods that are called by the >> PluginManager to turn a configuration text file into an object hierarchy >> with Loggers, Appenders, etc. >> It would be very rare for client code to call these methods directly. Which >> is why they are primarily called from JUnit tests. >> >> >> On Mon, Jun 16, 2014 at 11:45 PM, Paul Benedict <[email protected]> wrote: >> If this API is primarily for unit tests, then I don't care as much. I >> thought this was Public API. When it comes to Public API, I prefer to make >> it as friendly-to-read and maintainable as possible. >> >> >> Cheers, >> Paul >> >> >> On Mon, Jun 16, 2014 at 9:42 AM, Remko Popma <[email protected]> wrote: >> About the validation, wasn't the argument that some of the current JUnit >> tests look like this? >> FileAppender.createAppender("true", "true", "true", "true", "true", "true", >> "true", "4096", null, null, "false", null, null); >> >> So, null is fine here for at least four arguments. >> So it is definitely possible to forget to call the builder.setValue(value) >> method for those arguments >> - which is fine if your intention was to set null, but not if you forgot to >> set some non-null value. >> >> The compiler validates that you have the right number of arguments for free. >> It is not possible for builders to provide the same guarantee unless all >> arguments must be non-null. >> >> About the readability - and as Ralph pointed out this is readability in >> JUnit code primarily - there are a number of ways to accomplish that. >> >> >> >> On Mon, Jun 16, 2014 at 11:27 PM, Ralph Goers <[email protected]> >> wrote:
