On Sun, 17 Jul 2016 19:12:35 +0200, Hervé BOUTEMY <[email protected]>
wrote:
just keeping the option with Object will meaen that you must create a
String
to append it to the buffer: that's less memory-efficient
What do you mean: you must create a String? Because in the end
StringBuilder does a String.valueOf(Object)? I think we can assume that
most of the time it's a String being passed and that won't claim extra
memory.
And even with a very little bit of overhead I think it is worth over a
simple API. Removing these methods will also spare some memory :)
I understand that JAnsi chose for their implementation with reset() to
stay as close as possible to the actual implementation. But it is our job
have user-friendly wrapper.
Robert
if we stay with only one concept, let's remove the methods with Object
that
were suppose just to ease simple use cases
Do you really want that?
Regards,
Hervé
Le dimanche 17 juillet 2016 12:04:13 Robert Scholte a écrit :
On Sun, 17 Jul 2016 09:49:39 +0200, Hervé BOUTEMY
<[email protected]>
wrote:
> I worked on documentation to finish from my pov my work on this API:
> http://maven.apache.org/shared-archives/maven-shared-utils-LATEST/
>
> I'd like to release maven-shared-utils 3.1.0 to start releasing
plugins
> with
> styled messages, and of course work on releasing Maven 3.4.0-SNAPSHOT
>
> any objection?
> any improvement?
I'd love to see only MessageBuffer#method(Object message) signatures, so
we can remove the reset() since the already call reset() within those
methods.
Now it is a mixture of 2 concepts: one were the developer is responsible
for resetting it and the concept where every method does already the
reset.
This will reduce the number of methods and we have one clear concept.
Robert
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
