MapCollection failure!

[Matthew Cromer]

I tried to make an object and/or interface that implemented Collection and
Map. Basically, I want to be able to use a single interface to expose both
types of activity. Because both have a meaning for remove (Object) with
different return types I can't have an object implement both interfaces.
Is there some kind of work-around, or am I SOL?

Thanks,

Matthew Cromer

[Paul Clapham]

Technically, I guess you are SOL. But I can't quite conceive of an object
that would implement both interfaces. For example, what would be the
difference between the add() method from Collection and the put() method
from Map? Perhaps the Collection aspect of your object could be implemented
via the Map values() method, which returns a Collection?

Matthew Cromer <matthew@sdaconsulting.com> wrote in message
news:39a2da1a$1@news.devx.com...
>
> I tried to make an object and/or interface that implemented Collection and
> Map. Basically, I want to be able to use a single interface to expose
both
> types of activity. Because both have a meaning for remove (Object) with
> different return types I can't have an object implement both interfaces.
> Is there some kind of work-around, or am I SOL?
>
> Thanks,
>
> Matthew Cromer

[Matthew Cromer]

"Paul Clapham" <pclapham@core-mark.com> wrote:
>Technically, I guess you are SOL. But I can't quite conceive of an object
>that would implement both interfaces.

I'm writing such an object now. Actually an interface, which I call MapCollection,
and a GeneralMapCollection class. MapCollection implements Map and has some
collection-like features.

The point of this is to have a single base interface to use as a preferred
container, so when I need a container I can just use the MapCollection container.
That way, if I am not using keys today, I don't have to, and tomorrow when
I need keys (for faster lookup) I can use them without rewriting a bunch
of code.

Think of the Visual Basic Collection class. Yes, it sucks in 100 different
ways. However, it allows the optional use of keys. Therefore, when you
don't need keys you can use it, and when you later need to add key support
you can still use it. The lack of such a framework in Java is a very unfortunate
omission, IMHO.

Matthew Cromer

[Paul Clapham]

Good luck with your project. Just a comment -- it's almost possible to use
a Map to implement a Collection, just by using keys that map to null values.
Then the key part of the Map holds your collection and the values part is
all nulls. You can't have duplicate keys, so you are really implementing a
Set rather than a Collection.

Matthew Cromer <matthew@sdaconsulting.com> wrote in message
news:39a50ebf$1@news.devx.com...
>
> "Paul Clapham" <pclapham@core-mark.com> wrote:
> >Technically, I guess you are SOL. But I can't quite conceive of an
object
> >that would implement both interfaces.
>
> I'm writing such an object now. Actually an interface, which I call
MapCollection,
> and a GeneralMapCollection class. MapCollection implements Map and has
some
> collection-like features.
>
> The point of this is to have a single base interface to use as a preferred
> container, so when I need a container I can just use the MapCollection
container.
> That way, if I am not using keys today, I don't have to, and tomorrow
when
> I need keys (for faster lookup) I can use them without rewriting a bunch
> of code.
>
> Think of the Visual Basic Collection class. Yes, it sucks in 100
different
> ways. However, it allows the optional use of keys. Therefore, when you
> don't need keys you can use it, and when you later need to add key support
> you can still use it. The lack of such a framework in Java is a very
unfortunate
> omission, IMHO.
>
> Matthew Cromer