-
Notifications
You must be signed in to change notification settings - Fork 159
Refactor to remove SubscriptionHandle/ClientHandle/ServiceHandle #208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
bd64a89
Refactor to remove *Handle structs
nnmm ddbbca4
Introduce ServiceWaitable/ClientWaitable/SubscriptionWaitable
nnmm 91952c9
Add back the add_subscription() etc. methods to WaitSet
nnmm 15d62fa
Use the appropriate Waitable sub-trait everywhere
nnmm File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the
Waitable
s are now typed, we can keep the old style (Waitset::add_X(X)
). IMHO, it reads more logically that we add aSubscription
to aWaitset
. I'd agree more with the new style if we would have an arbitrary set of entities to be added to aWaitset
(the responsibility of adding an entity should therefore be in theWaitable
trait), but in this case, we know we won't have anything else other thanSubscription
s,Client
s,Service
s andTimer
s, so we can just have methods for each entity inWaitset
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we need to keep the actual logic in
Waitable::add_to_wait_set
(see PR description for why), but I added back the old functions as syntactic sugar.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've read the description again, but I'm afraid I'm not following, sorry. Is it because you don't want to give
pub(crate)
visibility torcl_wait_set
in theWaitset
? Is there a reason for that? To meWaitset::add_subscription
seems the natural "translattion" forrcl_wait_set_add_subscription
, so I would expect the logic for adding a subscription to be inWaitset
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, no, I'm fine with
pub(crate)
visibility for rcl types. But the issue is thatWaitSet::add_subscription()
needs anrcl_subscription_t
.Prior to this PR, the situation is as follows:
WaitSet::add_subscription()
takes the subscription in the form of adyn SubscriptionBase
, and therefore that trait must be able to provide thercl_subscription_t
. We don't want to have thercl_subscription_t
in the public API, soSubscriptionBase
returned thercl_subscription_t
in an opaque wrapper type, theSubscriptionHandle
.The main goal of this PR is to remove the
SubscriptionHandle
, since even though we now don't have thercl_subscription_t
in the public API, we now have thatSubscriptionHandle
in the public API which is also "internal" and has no useful functionality for the user. Fewer public types are better, as I'm sure you agree. It does that by changing thehandle()
method inSubscriptionBase
to not return thercl_subscription_t
handle, but just call the function that needs it directly, in this casercl_wait_set_add_subscription()
. (To have a more fitting name, that method was then renamed toadd_to_wait_set()
, and the trait generalized intoWaitable
.)So, I hope that makes sense – in Rust you cannot have a
pub(crate)
method on a trait, so all trait functions are public, so the way that theSubscriptionBase
trait gives thercl_subscription_t
to theWaitSet
is also public, unless we use the design in this PR.We could maybe make the organization feel more "natural" like you say by moving the impls of
Waitable
intowait.rs
. That way, the only place we deal withrcl_wait_set_*
functions is in thewait
module.A third design would be to make
WaitSet::add_subscription()
take an actualSubscription<T>
. Then we can just access the private parts, i.e.rcl_subscription_t
. This would mean theadd_to_wait_set()
function is removed. It has the drawback of causing a bit more monomorphization, and being more restrictive on user code, since they'll not be able to e.g. downcast several subscriptions into aSubscriptionBase
(orSubscriptionWaitable
, if you're fine with that) and store them into aVec
, before adding them to a wait set.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A fourth way is to keep
Handle
structs, but mark them as#[doc(hidden)]
. They will still be a bit annoying torclrs
developers though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, sorry I only realize this now, but I don't think option 3 would work. The node needs to store the subscriptions (and clients and services), and it must do so by storing trait objects, not the fully-typed
Subscription<T>
, orT
would need to become a type parameter ofNode
itself, which is impossible since there may be many subscriptions with differentT
s. And if it doesn't have the concrete type anymore, it cannot call aWaitSet::add_subscription()
that takes the concreteSubscription<T>
type.So my opinion is that the design in this PR is the best one I can think of. It The way things are currently done +
#[doc(hidden)]
is also acceptable – but if you don't like the design in this PR, I would like to learn more about why.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I actively dislike it, but I find it unnecessarily complicated. The responsibility of adding a subscription to a waitset should belong in a waitset IMHO, as it's the one that's storing the subscription's handle. But with this PR, in order to allow the entities to be added to a waitset, the waitset handle needs to be made public, which does not seem to me necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you mean the
rcl_wait_set_t
by "waitset handle", that's not public. The trait uses anrclrs::WaitSet
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we've used that nomenclature for a while, so yeah, by "waitset handle", I mean
rcl_wait_set_t
. It is public in the sense that aWaitable
needs access to it so it can callrcl_wait_set_add_X()
. I prefer that we keep the handle structures (i.e.rcl_X_t
) encapsulated inHandle
structs and move them to a separate module (or declare them as[doc(hidden)]
) so that developers know that these are internal.IMHO the design in this PR would be akin to having the logic of adding an item to a
std::vec
inside the item that is being added.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then let's leave this PR aside for a while and let me rework #224 to work with
SubscriptionHandle
. Then we can release and later worry about removingSubscriptionHandle
.