[
https://issues.apache.org/jira/browse/PROTON-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437419#comment-15437419
]
Andrew Stitcher commented on PROTON-1288:
-----------------------------------------
1. Strikes me as an interesting approach if it were applied across the api
consistently. So we could use it to get values also for those message
properties where they might also be null.
so there you might also have {{m.subject_value()}}, or {{m.to_value()}}.
I think this might be a pretty easy to remember API convention.
The other approaches are a bit neater in this one case, but I think 1. might
generalise better and give us an approach we can use elsewhere (instead of
adding {{has_to()}}, {{has_subject()}} etc.
> c++ provide access to message maps as proton::value
> ---------------------------------------------------
>
> Key: PROTON-1288
> URL: https://issues.apache.org/jira/browse/PROTON-1288
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Affects Versions: 0.14.0
> Reporter: Alan Conway
> Assignee: Alan Conway
> Fix For: 0.15.0
>
>
> We need to provide access to the message property maps as a proton::value.
> Given
> {code}
> std::map<string, scalar> my_map;
> proton::message m;
> {code}
> Here are some options:
> 1. Add new message accessor: proton::value& properties_value()
> proton::get(m.properties_value(), my_map)
> 2. Add value() accessor to cached_map
> proton::get(m.properties().value(), my_map)
> 3. Make cached_map : public proton::value()
> proton::get(m.properties(), my_map)
> 3 is neatest, 1 provides a clearer separation between the case where you want
> a convenient cached map vs. you want to decode to your own C++ map, work on
> it, and possibly re-encode it later. I lean towards 3. but open to persuasion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
