[SERVER-29864] Clarify/revisit how IDL-generated classes fit into larger C++ classes Created: 26/Jun/17  Updated: 08/Jan/24

Status: Open
Project: Core Server
Component/s: Internal Code
Affects Version/s: 3.5.9
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30763 Add support for relops in idl generat... Closed
related to SERVER-30764 Add support for hashing in idl genera... Closed
Assigned Teams:
Service Arch
Participants:

 Description   

The LogicalSessionId class inherits from Logical_session_id so that it can make use of the IDL-generated class' getters, setters, and parsing logic. The LogicalSessionId class is intended to be a value-add on top of the IDL-generated parsing code. This inheritance however makes it difficult to write code at the boundary between initialization and construction, because that requires casting from one type to the other.

We should revisit and clarify the way that C++ classes are meant to incorporate or compose with IDL-generated classes, and develop clear methods and guidelines for how to do that in a way that is more straightforward. We could consider recommending factory functions and static getters rather than using inheritance in cases like these.



 Comments   
Comment by Lauren Lewis (Inactive) [ 24/Feb/22 ]

We haven’t heard back from you for at least one calendar year, so this issue is being closed. If this is still an issue for you, please provide additional information and we will reopen the ticket.

Comment by Mark Benvenuto [ 31/Jul/17 ]

mira.carey@mongodb.com, gabriel.russell, and I have had a few ideas:

1. Add an ability to declare a class to derive from for Curiously recurring template pattern
2. Add the ability to generate relational operators (i.e., operator==, operation!=, operator<, operator >). This can be done by use std::tuple to do most of the work.
3. In lieu of #1, add the ability to simply inject C++ code from the IDL file into the generated header. The downside of this approach is this may break the containment of IDL generated classes, and break the contract of the generated IDL classes.

Comment by Kaloian Manassiev [ 07/Jul/17 ]

I don't have a good answer for what the ideal solution should be, but the two patterns that I encountered while working with IDL generated classes were:

The problems that arise with inheritance is that vectors of these objects are not castable to each other for example.

Generated at Thu Feb 08 04:22:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.