Dhanji R. Prasanna wrote:
>
>
> On 4/20/07, *Paul Sandoz* <Paul.Sandoz_at_sun.com
> <mailto:Paul.Sandoz_at_sun.com>> wrote:
>
> Dhanji R. Prasanna wrote:
> >
> > Is there some value to us putting some sort of numbering or naming
> > scheme around each of these proposals, so we can formalize
> referring to
> > them? Perhaps at the head of the thread, like Marc does with code
> > snippets? I think we're going to run into a lot of formers and
> latters
> > otherwise ;)
>
> I really was referring to latter/former in reference to what you were
> saying :-)
>
>
> People who live in glass houses...I really ought to pick better
> identifiers =)
Tis really my fault! sorry!
> Just to clarify, if we used the builder approach as the high-level
> (only) case I assume it would mean moving it out of the core into the
> root package as the standard case?
>
Not sure it needs to be moved. The 'core' package in 'sketch 2' has sort
of evolved to be mostly anything other than annotations and spi classes.
> but i agree having some formal identifiers would be useful
> when discussing.
>
>
>
>
> See the JavaDoc of MultivaluedMap [1]. It does not break the contract of
> Map:
>
> public interface MultivaluedMap<K,V>
> extends java.util.Map<K,java.util.List<V>>
>
>
> Ahh I missed that the first time around (got caught up in commons
> MultiMap). This certainly puts a different spin on it. Consider my
> objection officially withdrawn. =)
>
OK!
> I was referring to the use of Map not to the fact there can be multiple
> values. I was wondering in this case whether List may be appropriate.
>
>
> Do you mean a list of returned metadata (i.e. headers)? Are you thinking
> of something like List<HeaderValue>?
>
Yes, or something generic like:
List<Pair<String, T>>
Namely this links back to the RESTlet approach. It would be useful to
compare the pros/cons as this is quite a fundamental abstraction.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109