You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Adam Gent (JIRA)" <ji...@apache.org> on 2010/02/10 21:35:27 UTC
[jira] Created: (COLLECTIONS-352) AbstractCollectionDecorator is
inconsistent with AbstractListDecorator. Uses private member variable
instead of protected getter
AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter
--------------------------------------------------------------------------------------------------------------------------------
Key: COLLECTIONS-352
URL: https://issues.apache.org/jira/browse/COLLECTIONS-352
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2, 3.1, 3.0
Reporter: Adam Gent
Priority: Minor
AbstractListDecorator uses getList() to access its private member variable for its methods:
{code}
public int indexOf(Object object) {
return getList().indexOf(object);
}
{code}
Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor):
{code}
public static class FutureList<T> extends AbstractListDecorator {
private Future<List<T>> futureList;
public FutureList(Future<List<T>> futureList)
{
super();
this.futureList = futureList;
}
@Override
protected Collection<T> getCollection()
{
try
{
return futureList.get();
}
catch (InterruptedException e)
{
throw new RuntimeException(e);
}
catch (ExecutionException e)
{
throw new RuntimeException(e);
}
}
}
{code}
But AbstractCollectionDecorator uses its private member variable
{code}
public boolean add(Object object) {
return collection.add(object);
}
{code}
When it should be IMHO:
{code}
public boolean add(Object object) {
return getCollection().add(object);
}
{code}
Of course most everybody has an armpit and an opinion :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COLLECTIONS-352) AbstractCollectionDecorator is
inconsistent with AbstractListDecorator. Uses private member variable
instead of protected getter
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COLLECTIONS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell closed COLLECTIONS-352.
-------------------------------------
Fix Version/s: 4.0
Resolution: Fixed
4.0 uses decorated() and both classes are using it instead of the private variable.
> AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-352
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-352
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
> Affects Versions: 3.0, 3.1, 3.2
> Reporter: Adam Gent
> Priority: Minor
> Fix For: 4.0
>
>
> AbstractListDecorator uses getList() to access its private member variable for its methods:
> {code}
> public int indexOf(Object object) {
> return getList().indexOf(object);
> }
> {code}
> Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor):
> {code}
> public static class FutureList<T> extends AbstractListDecorator {
> private Future<List<T>> futureList;
> public FutureList(Future<List<T>> futureList)
> {
> super();
> this.futureList = futureList;
> }
> @Override
> protected Collection<T> getCollection()
> {
> try
> {
> return futureList.get();
> }
> catch (InterruptedException e)
> {
> throw new RuntimeException(e);
> }
> catch (ExecutionException e)
> {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> But AbstractCollectionDecorator uses its private member variable
> {code}
> public boolean add(Object object) {
> return collection.add(object);
> }
> {code}
> When it should be IMHO:
> {code}
> public boolean add(Object object) {
> return getCollection().add(object);
> }
> {code}
> Of course most everybody has an armpit and an opinion :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-352) AbstractCollectionDecorator is
inconsistent with AbstractListDecorator. Uses private member variable
instead of protected getter
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COLLECTIONS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell updated COLLECTIONS-352:
--------------------------------------
Fix Version/s: 4.0-beta-1
(was: 4.0)
> AbstractCollectionDecorator is inconsistent with AbstractListDecorator. Uses private member variable instead of protected getter
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-352
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-352
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
> Affects Versions: 3.0, 3.1, 3.2
> Reporter: Adam Gent
> Priority: Minor
> Fix For: 4.0-beta-1
>
>
> AbstractListDecorator uses getList() to access its private member variable for its methods:
> {code}
> public int indexOf(Object object) {
> return getList().indexOf(object);
> }
> {code}
> Which allows me to almost do something like this (notice I'm taking some liberties here with the no-arg serialization constructor):
> {code}
> public static class FutureList<T> extends AbstractListDecorator {
> private Future<List<T>> futureList;
> public FutureList(Future<List<T>> futureList)
> {
> super();
> this.futureList = futureList;
> }
> @Override
> protected Collection<T> getCollection()
> {
> try
> {
> return futureList.get();
> }
> catch (InterruptedException e)
> {
> throw new RuntimeException(e);
> }
> catch (ExecutionException e)
> {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> But AbstractCollectionDecorator uses its private member variable
> {code}
> public boolean add(Object object) {
> return collection.add(object);
> }
> {code}
> When it should be IMHO:
> {code}
> public boolean add(Object object) {
> return getCollection().add(object);
> }
> {code}
> Of course most everybody has an armpit and an opinion :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.