> On 2014/06/17, at 0:40, Ralph Goers <[email protected]> wrote: > > 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.
For programmatic configuration, why wouldn't you just call a constructor? > > 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: >
