Rename variables of rcl types

[nnmm]

I find it confusing and not very descriptive that "handle" is used to refer to both any rcl binding struct, and the PublisherHandle etc. types.

This PR changes the variable names of rcl binding types to be more descriptive, e.g. use rcl_node as the variable name for an rcl_node_t. Afterwards, "handle" refers exclusively to the PublisherHandle etc. types.

What's maybe worth discussing: Is rcl_node also fine for a &mut rcl_node_t?

[esteve]

I find it the opposite, I like the uniformity that every wrapped rcl entity has the same field, rclpy and rcljava do that, for example. It's more confusing if every struct has a different name for what is essentially the same (a pointer to the underlying native structure).

What I'd prefer is instead getting rid of the handle structs (like PublisherHandle struct) and use rcl_publisher_t as the value for the handle field directly.

[jhdcs]

I can (unfortunately) see it going both ways - to some people, it's probably easier to think about if the names are completely uniform (like what Esteve suggested). To other people, the explicit naming of the underlying type could be useful (which I think is what Nikolai is going for with this PR).

Personally, like Nikolai, I like the explicit naming of the underlying type. However, since this is admittedly my first time writing a client library, my preferences may not be fully in-line with what more experienced developers of client libraries are comfortable with. On the other hand, how many developers of client libraries are going to start moving over to work on ros2_rust from one of their other projects?

Perhaps we should bring this up at the next working group meeting, and get some community feedback? See which style is the most clear to the most people? Our ultimate goal should be readability to the maximum number of people, so as to encourage more participation in the creation/maintenance of the library. At least that's how I see it.

[nnmm]

@esteve I had a brief look into one file in rclpy, and it seems they use my proposed naming convention too: https://github.com/ros2/rclpy/blob/2c8ffe098eefebeec5a49e906e2506da4e0db434/rclpy/src/rclpy/publisher.cpp#L49

[esteve]

@nnmm you're right, I recall using handle in rclpy at some point, that must have changed when rclpy moved to C++ from C. Anyway, if you and @jhdcs agree on the same naming conventions, that's settled 🙂

One thing, is that I'd like the *Handle structs go away, they don't seem to be necessary any more.

[nnmm]

@esteve Ok, then I'll implement Drop on Publisher and Subscription.

[esteve]

@nnmm thanks! That change can be done in a separate PR if that's more convenient.

[nnmm]

Yes, let's do that.

[esteve]

@nnmm do you want to merge this first or you'd rather wait for the PR removing the *Handle structs?

[nnmm]

@esteve This one first (but after 186), since it's already open.

[nnmm]

@esteve @jhdcs I had to rebase, could one of you re-approve?