[xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder
23 Mar
2012
23 Mar
'12
7:55 a.m.
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
So here's my +1. My only doubt is where to put it. Right now I'd be tempted to put
it in xwiki-commons-logging so that we don't create a new module.
Thanks
-Vincent
23 Mar
23 Mar
8:41 a.m.
New subject: [xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder
On Fri, Mar 23, 2012 at 7:55 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
What about a XWikiToStringBuilder (or just ToStringBuilder since it's
in a XWiki package which makes it different already) which extends
ToStringBuilder and set XWikiStyle as default style ?
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
* xwiki-commons-lang (new module): to follow the same logic as Apache
commons naming.
So here's my +1.
+1, I'm already using HashCodeBuilder and EqualsBuilder when the
equals is starting to be complex (I tough I had answered to the mail
actually :))
My only doubt is where to put it. Right now I'd be
tempted to put it in xwiki-commons-logging so that we don't create a new module.
I'm not sure either. I would say +1 for xwiki-commons-lang with as
less dependencies as possible (probably only apache commons-lang), if
we want all module to use it as standard toString lets make it as
light as possible. Right now there is very few modules that need
logging-api (it's not required to log) so I would prefer avoid having
to put it in dependency only for a toString. It would also avoid
circular dependency issues if for example we want to us XWiki
ToStringBuilder in any of logging-api dependencies like
observation-api or components-api.
Other possibility is xwiki-commons-component-api since everything
already depends on it but it's not really component domain so I don't
like it too much.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9:25 a.m.
On Mar 23, 2012, at 8:41 AM, Thomas Mortagne wrote:
Ok for xwiki-commons-lang for now but I'm not sure I like it that much. When it starts
to grow and there will be several classes for a given domain I think I'll prefer to
move the code to its own module. Like we do with xwiki-commons-xml for example. Which is
why I had suggested xwiki-commons-text …
It looks better to me to have xwiki-commons-xml and xwiki-commons-text side by side.
BTW the reason for "text" is because that's the package used by commons-lang
for this ;)
WDYT?
Thanks
-Vincent
On Fri, Mar 23, 2012 at 7:55 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Yep good idea, done here:
https://github.com/xwiki/xwiki-rendering/commit/bf7e97690685a7864eae592a508…
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
What about a XWikiToStringBuilder (or just ToStringBuilder since it's
in a XWiki package which makes it different already) which extends
ToStringBuilder and set XWikiStyle as default style ? And then to
use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
* xwiki-commons-lang (new module): to follow the same logic as Apache
commons naming.
So here's my +1.
+1, I'm already using HashCodeBuilder and EqualsBuilder when the
equals is starting to be complex (I tough I had answered to the mail
actually :))
My only doubt is where to put it. Right now
I'd be tempted to put it in xwiki-commons-logging so that we don't create a new
module.
I'm not sure either. I would say +1 for xwiki-commons-lang with as
less dependencies as possible (probably only apache commons-lang), if
we want all module to use it as standard toString lets make it as
light as possible. Right now there is very few modules that need
logging-api (it's not required to log) so I would prefer avoid having
to put it in dependency only for a toString. It would also avoid
circular dependency issues if for example we want to us XWiki
ToStringBuilder in any of logging-api dependencies like
observation-api or components-api.
Other possibility is xwiki-commons-component-api since everything
already depends on it but it's not really component domain so I don't
like it too much.
9:34 a.m.
New subject: [xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder
On Fri, Mar 23, 2012 at 9:25 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Mar 23, 2012, at 8:41 AM, Thomas Mortagne wrote:
Ok for xwiki-commons-lang for now but I'm not sure I like it that much. When it
starts to grow and there will be several classes for a given domain I think I'll
prefer to move the code to its own module. Like we do with xwiki-commons-xml for example.
Which is why I had suggested xwiki-commons-text …
It looks better to me to have xwiki-commons-xml and xwiki-commons-text side by side.
BTW the reason for "text" is because that's the package used by
commons-lang for this ;)
I'm ok with xwiki-commons-text too, I'm mostly against putting it in a
module which depends on other commons modules.
On Fri, Mar 23, 2012 at 7:55 AM, Vincent Massol
<vincent(a)massol.net> wrote:
Yep good idea, done here:
https://github.com/xwiki/xwiki-rendering/commit/bf7e97690685a7864eae592a508…
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
What about a XWikiToStringBuilder (or just ToStringBuilder since it's
in a XWiki package which makes it different already) which extends
ToStringBuilder and set XWikiStyle as default style ? And then
to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
* xwiki-commons-lang (new module): to follow the same logic as Apache
commons naming.
So here's my +1.
+1, I'm already using HashCodeBuilder and EqualsBuilder when the
equals is starting to be complex (I tough I had answered to the mail
actually :))
My only doubt is where to put it. Right now
I'd be tempted to put it in xwiki-commons-logging so that we don't create a new
module.
I'm not sure either. I would say +1 for xwiki-commons-lang with as
less dependencies as possible (probably only apache commons-lang), if
we want all module to use it as standard toString lets make it as
light as possible. Right now there is very few modules that need
logging-api (it's not required to log) so I would prefer avoid having
to put it in dependency only for a toString. It would also avoid
circular dependency issues if for example we want to us XWiki
ToStringBuilder in any of logging-api dependencies like
observation-api or components-api.
Other possibility is xwiki-commons-component-api since everything
already depends on it but it's not really component domain so I don't
like it too much.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9:17 a.m.
New subject: [xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder
+1
Best regards,
Andreas
2012-03-23 07:55, Vincent Massol skrev:
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
So here's my +1. My only doubt is where to put it. Right now I'd be tempted to
put it in xwiki-commons-logging so that we don't create a new module.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:22 a.m.
I have implemented it locally here if you wish to have a look at both the implementation
and its usage:
https://github.com/xwiki/xwiki-rendering/commit/bf7e97690685a7864eae592a508…
Thanks
-Vincent
On Mar 23, 2012, at 7:55 AM, Vincent Massol wrote:
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
So here's my +1. My only doubt is where to put it. Right now I'd be tempted to
put it in xwiki-commons-logging so that we don't create a new module.
Thanks
-Vincent
25 Mar
25 Mar
2:21 p.m.
New subject: [xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder (SUMMARY)
Vote result:
+1: 3
0: 0
-1: 0
The vote is passed. I'll add a xwiki-commons-text module which is supposed to contain
various generic text APIs and which FTM will only contain XWiki's ToStringBuilder.
I've documented the best practice here:
http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HEquals2FHashCo…
Thanks
-Vincent
On Mar 23, 2012, at 7:55 AM, Vincent Massol wrote:
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
* xwiki-commons-util (new module): I don't like to have a module with no specific
domain but it could be temporary till there are more stuff that make a domain
So here's my +1. My only doubt is where to put it. Right now I'd be tempted to
put it in xwiki-commons-logging so that we don't create a new module.
Thanks
-Vincent
9:08 p.m.
New subject: [xwiki-devs] [VOTE] Standardize on Commons Lang EqualsBuilder, HashCodeBuilder and ToStringBuilder
On Fri, Mar 23, 2012 at 8:55 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
I've already sent a proposal for EqualsBuilder and HashCodeBuilder (see
http://markmail.org/message/ewbizvcx4zj432il) but only Sergiu answered. So resending as a
VOTE and adding ToStringBuilder
For ToStringBuilder the idea is to create a XWikiStyle (see
https://gist.github.com/2164507 )
And then to use it as in:
@Override
public String toString()
{
ToStringBuilder builder = new ToStringBuilder(this, new XWikiStyle());
builder = builder.append("Typed", isTyped())
.append("Type", getType().getScheme());
if (getReference() != null) {
builder = builder.append("Reference", getReference());
}
if (!getBaseReferences().isEmpty()) {
builder = builder.append("Base References", getBaseReferences());
}
Map<String, String> params = getParameters();
if (!params.isEmpty()) {
builder = builder.append("Parameters", params);
}
return builder.toString();
}
For the record this generates stuff like the following which is based on our current
practices:
"Typed = [true] Type = [doc] Reference = [reference] Base References = [[baseref1],
[baseref2]] Parameters = [[name1] = [value1], [name2] = [value2]]"
The rationale for using ToStringBuilder is:
* It reduces our boilerplate code by at least 50%
* It makes all our toString implementation consistent and easy to write
Now all that remains is to decide where to put the XWikiStyle class. Of course it has to
go in XWiki Commons somewhere but where?
I'm proposing several possibilities:
* xwiki-commons-logging (existing module): the rationale would be that the toString() is
usually used for logging. The package would be org.xwiki.logging.text. I'm wondering
if we should make this class internal too.
* xwiki-commons-text (new module): I'm not sure what else we would put in there
+1
Thanks,
Marius
* xwiki-commons-util (new module): I don't like to
have a module with no specific domain but it could be temporary till there are more stuff
that make a domain
So here's my +1. My only doubt is where to put it. Right now I'd be tempted to
put it in xwiki-commons-logging so that we don't create a new module.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4611
days inactive
4613
days old
7 comments
4 participants
participants (4)
-
Andreas Jonsson -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol