+1 - definitely the best so far.
--- ASHWIN Suresh <[EMAIL PROTECTED]> wrote:
>
>
> > I'll suggest keyvalue to positively describe the package (rather
> than
> > negatively). That name allows MapEntry, KeyValue and MultiKey.
> >
> > (data/holders/elements all seem a bit vague)
> >
> > Stephen
> I'll suggest keyvalue to positively describe the package (rather than
> negatively). That name allows MapEntry, KeyValue and MultiKey.
>
> (data/holders/elements all seem a bit vague)
>
> Stephen
+1
Ashwin
-
To unsubscribe
Stephen Colebourne wrote:
I'll suggest keyvalue to positively describe the package (rather than
negatively). That name allows MapEntry, KeyValue and MultiKey.
(data/holders/elements all seem a bit vague)
Stephen
+1
Phil
-
To un
Maybe I just need to dig into this more deeply, but I find any form of
Pair or Object[2] class being exposed as a public interface of
commons-collections a bit questionable.
On Wed, 3 Dec 2003, __matthewHawthorne wrote:
> o.a.c.c.data could work.
>
> some other ideas:
> o.a.c.c.types
> o.a.c.c.el
"data" would be fine but somehow I feel a name like that is too generic.
I mean, it's all data! So, the name did rather describe what the classes do
with data.
So, one might call it:
oacc.dataholders
Or, if that is long, how about just oacc.holders
Or something that describes that these eleme
o.a.c.c.data could work.
some other ideas:
o.a.c.c.types
o.a.c.c.elements
Stephen Colebourne wrote:
KeyValue is not directly associated with maps - its a free form key value
pair. MultiKey could also be used in a List or Set.
Stephen
- Original Message -
From: "Rodney Waldhoff" <[EMAIL
KeyValue is not directly associated with maps - its a free form key value
pair. MultiKey could also be used in a List or Set.
Stephen
- Original Message -
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
> Why can't these all just go with the maps?
>
> On Wed, 3 Dec 2003, Stephen Colebourne wr
Why can't these all just go with the maps?
On Wed, 3 Dec 2003, Stephen Colebourne wrote:
> The pairs package name is perhaps not quite right. I would like the package
> to hold all non-collection data structure:
> - MapEntry
> - KeyValue
> - MultiKey
>
> How about renaming the package to data?
The pairs package name is perhaps not quite right. I would like the package
to hold all non-collection data structure:
- MapEntry
- KeyValue
- MultiKey
How about renaming the package to data?
(no backwards compatability issues)
Stephen
