But I already did notice that there are drawbacks with mandatory names ... the 
single value Edgent suppliers for example ... here I need to set a name, even 
if it's not needed and implicitly given by the pipeline I am plumbing together 
...

Chris

Am 19.02.18, 16:39 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

    Hi Dale,
    
    I agree ... we should make it mandatory.
    Let's hear what the others have to say.
    
    Chris
    
    Am 19.02.18, 16:23 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
    
        I think I’m generally +1 on this, though I think *optional* names may 
just make it harder / less predictable to use these objects.  Why not just 
require names?  This also relates to the usability of a batch request/response 
object, and the ability to offer a get-item-by-name accessor, instead of just 
get-item-by-meaningless-index :-)
        
        Since a ResponseItem has an associated RequestItem, there seems to be 
no need for it to have it’s own name (regardless of memory impact).  Though for 
convenience, it could still have a getName() accessor (that was just 
getRequestItem().getName()).
        
        — Dale
        
        > On Feb 19, 2018, at 9:11 AM, Christofer Dutz 
<christofer.d...@c-ware.de> wrote:
        > 
        > Hi all,
        > 
        > I’m currently whipping up a first POC for usage on a real machine 
(Not just our companies Christmas tree) ;-)
        > While at it, I did notice again what I had noticed a few times 
before: It would be cool if we could assign a “name” or “alias” to a request 
item.
        > With this for example I could auto-serialize a read-response with 
meaningful names. I would make it optional, but I think it could be helpful.
        > Also I wouldn’t assign it to the response items, but just the request 
items so the amount of memory used would be minimal.
        > 
        > What do you think?
        > 
        > Chris
        
        
    
    

Reply via email to