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: > >
