dev@jsr311.java.net

Re: Consume/Produce and Input/Output

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 21 May 2007 14:50:59 +0200

Hi Jerome,

What are the advantages to allowing one to annotate a method parameter?

Paul.

Jerome Louvel wrote:
> Hi Paul,
>
> I think that the answer to those questions is unique. If people prefer some
> more precise terms, here are some alternatives to Input/Output:
> - InputEntity / OutputEntity
> - InputContent / OutputContent
> - RequestEntity / ResponseEntity
> - RequestContent / ResponseContent
>
> Now, ConsumeContent/ProduceContent are nice names too, but they have a
> disadvantage: they can't be used as parameter annotations because it
> wouldn't make sense:
>
> public void put(@ConsumeContent String value){
> ...
> }
>
> while @Input (or similar alternatives) is more flexible and can annotate
> either the class, the method or the parameter:
>
> public void put(@Input String value){
> ...
> }
>
> Best regards,
> Jerome
>
>> -----Message d'origine-----
>> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
>> Envoyé : vendredi 18 mai 2007 14:34
>> À : dev_at_jsr311.dev.java.net
>> Objet : Consume/Produce and Input/Output
>>
>> Hi Jerome,
>>
>> I think there are two separate issues:
>>
>> 1) The more general annotations for the support of additional
>> content for negotiation; and
>>
>> 2) The placement of those annotations on classes/methods/parameters.
>>
>>
>> 1)
>> ---
>>
>> I don't detect any general disagreement over 1, although i
>> would like to
>> hear more opinions on this by others.
>>
>> IMHO the Input/Output names are too vague. I would prefer
>> something more
>> descriptive and accurate, for example
>> ConsumeContent/ProduceContent. The
>> use of consume/produce also tends to read very nicely when
>> expressed in
>> sentences (at least in English!) about a resource or a method
>> of a resource.
>>
>> I guess we could argue over Input vs. Consume till entropy
>> death of the
>> universe, life is too short :-) the only strong opinion i
>> have is that
>> the annotation names clearly reflect what they are specified to do so
>> that developers can make intuitive guesses.
>>
>>
>> 2)
>> ---
>>
>> IIRC Marc has discussed this before in other email threads.
>> But it has
>> been a long time. Perhaps you could refresh our memories and
>> summarize
>> the differences/commonalities/pros/cons of the two positioning
>> approaches from your perspective?
>>
>> Paul.
>>
>> --
>> | ? + ? = To question
>> ----------------\
>> Paul Sandoz
>> x38109
>> +33-4-76188109
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109