[jira] [Comment Edited] (THRIFT-2471) Make cpp.ref annotation language agnostic

["Randy Abernethy (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972321#comment-13972321 ] 

Randy Abernethy edited comment on THRIFT-2471 at 4/17/14 5:42 AM:
------------------------------------------------------------------

Hey Jens & Dave, thanks for the brain dump on #thrift. 

I see Dave's point, in the A >> B >> A scenario I can imagine a case where the semantic of A >> B is composition, implying that A has a B value, and the semantic of B >> A is association, implying B may refer to an A with a reference. The interface designer would need to be explicit here, precisely because the interface semantics are different. 

Adding references to Thrift is a big step, I don't see it as a language-centric addition though. I suspect developers would be surprised if an interface says A contains a B and in some languages you don't get a B. If the semantic is composition we should make sure that at the Thrift level there is always a B for every A, even in Python and other dynamic languages. 

I found a bit of production MIDL using composition & association that helped me think this over. The Plan struct here has a TimeStamp (composition) and a Wave reference (association). When you create a Plan you get a TimeStamp but not a Wave (regardless of your implementation language). You can attach a Wave, detach a Wave, swap Waves but the TimeStamp is a fixed part of Plan. 
{code:title=old.idl|borderStyle=solid}
typedef struct _Plan
{
   ...
   TimeStamp   entryDateTime;
   Wave*       waveArray;
   ...
} Plan;
{code}

Thrift was purely Composition based prior to the addition of cpp.ref. I think cpp.ref made perfect sense in the context used and, as I understand it, the approach was to only support DAGs, which simplifies things. As I read the tree support code in THRIFT-2422, each object is serialized in place and if an object appears twice in the graph it is serialized twice (essentially treated as two separate copies of the same object). If your trees only contain unique nodes this is simple and efficient. If your graph instances contain cycles (e.g. THRIFT-2462) we will need to essentially do what graph<> (THRIFT-2005) contemplates and serialize objects based on identity not based on the digraph.

So right now we have a way to countermand Thrift’s default composition semantics but only in C++ and only with DAG support. I think Jens is correct to seek a way to enable reference semantics universally. I also feel like reference semantics are a pretty big deal and mark a material new addition to Thrift, warranting a new serialization approach (if we plan to support instance cycles). 

My read on annotations is that they are for manipulating the implementation independent of the interface. For example, making a type final/sealed in some languages, or using a hash set instead of a BTree set in some language. These things don’t affect the interface, only the implementation. What we contemplate with references provides a big new interface feature as I see it, and it needs to be the same semantic in every language. This motivates me to prefer an IDL construct to an annotation. Just my 2 cents.

Best,
Randy


was (Author: codesf):
Hey Jens & Dave, thanks for the brain dump on #thrift. 

To Dave's point, in the A >> B >> A scenario I can imagine a case where the semantic of A >> B is composition, implying that A has a B value, and the semantic of B >> A is association, implying B may refer to an A with a reference. The interface designer would need to be explicit here, precisely because the interface semantics are different. 

Adding references to Thrift is a big step, I don't see it as a language-centric addition. I suspect developers would be surprised if an interface says A contains a B and in some languages you don't get a B. If the semantic is composition we should make sure that at the Thrift level there is always a B for every A, even in Python and other dynamic languages. 

I found a bit of production MIDL using composition & association that helped me think this over. The Plan struct here has a TimeStamp (composition) and a Wave reference (association). When you create a Plan you get a TimeStamp but not a Wave (regardless of your implementation language). You can attach a Wave, detach a Wave, swap Waves but the TimeStamp is a fixed part of Plan. 
{panel}
typedef struct _Plan
{
   ...
   TimeStamp   entryDateTime;
   Wave*       waveArray;
   ...
} Plan;
{panel}

Thrift was purely Composition based prior to the addition of cpp.ref. I think cpp.ref made perfect sense in the context used and, as I understand it, the approach was to only support DAGs, which simplifies things. As I read the tree support code in THRIFT-2422, each object is serialized in place and if an object appears twice in the graph it is serialized twice (essentially treated as two separate copies of the same object). If your trees only contain unique nodes this is simple and efficient. If your graph instances contain cycles (e.g. THRIFT-2462) we will need to essentially do what graph<> (THRIFT-2005) contemplates and serialize objects based on identity not based on the digraph.

So right now we have a way to countermand Thrift’s default composition semantics but only in C++ and only with DAG support. I think Jens is correct to seek a way to enable reference semantics universally. I also feel like reference semantics are a pretty big deal and mark a material new addition to Thrift, warranting a new serialization approach (if we plan to support instance cycles). 

My read on annotations is that they are for manipulating the implementation independent of the interface. For example, making a type final/sealed in some languages, or using a hash set instead of a BTree set in some language. These things don’t affect the interface, only the implementation. What we contemplate with references provides a big new interface feature as I see it, and it needs to be the same semantic in every language. This motivates me to prefer an IDL construct to an annotation. Just my 2 cents.

Best,
Randy

> Make cpp.ref annotation language agnostic
> -----------------------------------------
>
>                 Key: THRIFT-2471
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2471
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Compiler (General)
>            Reporter: Jens Geyer
>
> The proposal is to make the new {{cpp.ref}} annotation introduced with THRIFT-2421 language agnostic instead of a C++ specialty only. 
> The annotation changes inlined nested structs into pointers to structs. This behaviour is potentially relevant with all languages using value semantics for nested structs etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)