I'd support deprecating the with methods and making set methods the
canonical one.
As for is versus get, is it because some of them return Boolean rather than
boolean? I generally prefer the is prefix for boolean and avoid using
Boolean whenever possible.
On 14 November 2016 at 17:37, Gary Gregor
I marked existing methods @Deprecated. I did not delete anything in order
to avoid breaking BC as much as possible.
I'd like to change the existing Builders that use "with" to "set". This
would not break config files but it would break code. Is it over the top to
deprecate the "with" methods and a
Of course only for the Builders that were published as of 2.7. The Builders
we're adding in 2.8 can just use set.
Sent from my iPhone
> On 15 Nov 2016, at 8:26, Remko Popma wrote:
>
> Are Builders used by users for custom plugins?
> Should we deprecate and keep the old methods around for a wh
Are Builders used by users for custom plugins?
Should we deprecate and keep the old methods around for a while to avoid
breaking user code?
Remko
Sent from my iPhone
> On 15 Nov 2016, at 5:22, Matt Sicker wrote:
>
> I like using set instead of with for builders. I've only been using with
> m
I like using set instead of with for builders. I've only been using with
methods lately for constructing modified copies of the current object which
doesn't exactly fit the builder idea (since the builder is modified and not
copied). I've also used builders without any prefix, but that would look
r
I recently added a bunch of Builders in various places and used "with" as
the setter method prefix.
We have a mix of "set" and "with" in our Builders ATM.
I am thinking of going back and changing the builders I added since 2.7
from "with" to "set".
I am liking "set" better because:
- More standa
I was thinking of using a different annotation for the builder attributes
(at least for PluginAttribute) because the fields themselves have their own
default values. I'm going to refactor that soon to show what I mean. I
noticed the smell, too. ;)
On 28 May 2014 21:58, Gary Gregory wrote:
> The
The "normal" plugin pattern looks like this:
@PluginFactory
public static PatternLayout createLayout(
@PluginAttribute(value = "pattern", defaultStringValue =
DEFAULT_CONVERSION_PATTERN) final String pattern,
@PluginConfiguration final Configuration config,
