On Mon, Jun 16, 2014 at 12:04 PM, Remko Popma <remko.po...@gmail.com> wrote:
>
> On 2014/06/17, at 0:40, Ralph Goers <ralph.go...@dslextreme.com> 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?
>
Because the ctor is private and the factory method is public?
Gary
>
>
> Ralph
>
> On Jun 16, 2014, at 8:36 AM, Remko Popma <remko.po...@gmail.com> wrote:
>
>
>
> On Tuesday, June 17, 2014, Ralph Goers <ralph.go...@dslextreme.com> 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 <boa...@gmail.com> 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 <garydgreg...@gmail.com> 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 <remko.po...@gmail.com>
>> 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 <pbened...@apache.org>
>> 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 <remko.po...@gmail.com>
>> 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 <ralph.go...@dslextreme.com
>> > wrote:
>>
>>
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
