Comments (7)
From my point of view when using dependency injection (which the context object is) the code can usually be used more flexible. Especially when it comes to testing it is much easier with DI then when the code uses singletons internally (which the ROS 1 code relies on heavily).
Just a few random references on the topic:
- http://googletesting.blogspot.de/2008/05/tott-using-dependancy-injection-to.html
- http://stackoverflow.com/questions/2662842/dependency-injection-singleton-design-pattern
from rclcpp.
It's also worth noting that if you do not specify a Context, nodes use a singleton Context.
from rclcpp.
from rclcpp.
thanks, i'm just trying to understand the ros2 code. The Context looked "weird". The links were very helpful. Why is the context not just a service locator (which is apparently also bad(tm) according to stack overflow)?
from rclcpp.
Well, the rclcpp::Context
object is sort of a service locator, since you can get a sub-context of any type as a singleton. So nodes ask the context for information they need to complete the intra process task, which is part of the definition from wikipedia:
https://en.wikipedia.org/wiki/Service_locator_pattern
This pattern uses a central registry known as the "service locator", which on request returns the information necessary to perform a certain task.
However, this is also like a singleton, since the is no "register" step for the information, it is just created if it doesn't already exist. For example, this is how the intra process manager singleton is gotten by the nodes:
https://github.com/ros2/rclcpp/blob/release-alpha1/rclcpp/include/rclcpp/node_impl.hpp#L149-L150
https://github.com/ros2/rclcpp/blob/release-alpha1/rclcpp/include/rclcpp/context.hpp#L43-L73
Basically nodes which share a Context also share any "singleton" "services" with each other. The more traditional "service locator" pattern would involve either a plugin system (where code is lookup and loaded dynamically) or something like the Windows registry. You could consider the DDS global configuration file a service locator I guess, a la OpenSplice's OSPL_URI
env variable.
My opinion is that the "service locator" pattern leads to centralized and hierarchical designs which lead to globals and configuration complexity. The Context pattern, which is used by may systems e.g. OpenGL, allows for composition and decoupling of the configuration for parts of the system. But if you can come up with a rational to organize it differently I'm willing to consider it.
from rclcpp.
Dirk's links led to a large amount of reading over the weekend, and there
are a lot of conflicting opinions on single class instance mechanims
(singletons, contexts, locators etc.) For example, I am pretty sure there
was an article stating contexts were evil, which I did not quite agree
with. I am just trying to understand the design decisions that have been
made and the rationale.
is it my job to close issues, or do you all do that?
On Mon, Sep 14, 2015 at 4:16 PM, William Woodall [email protected]
wrote:
Well, the rclcpp::Context object is sort of a service locator, since you
can get a sub-context of any type as a singleton. For instance, this is how
the intra process manager singleton is gotten by the nodes:https://github.com/ros2/rclcpp/blob/release-alpha1/rclcpp/include/rclcpp/node_impl.hpp#L149-L150
https://github.com/ros2/rclcpp/blob/release-alpha1/rclcpp/include/rclcpp/context.hpp#L43-L73
Basically nodes which share a Context share a any "singleton" "services"
with each other. The more traditional "service locator" pattern would
involve either a plugin system (where code is lookup and loaded
dynamically) or something like the Windows registry. You could consider the
DDS global configuration file a service locator I guess, a la OpenSplice's
OSPL_URI env variable.My opinion is that the "service locator" pattern leads to centralized and
hierarchical designs which lead to globals and configuration complexity.
The Context pattern, which is used by may systems e.g. OpenGL, allows for
composition and decoupling of the configuration for parts of the system.
But if you can come up with a rational to organize it differently I'm
willing to consider it.—
Reply to this email directly or view it on GitHub
#110 (comment).
from rclcpp.
@BobDean the feedback is welcome! Design patterns are rarely agreed on unanimously. The context seems appropriate here to me, and my intuition is to continue until we have cause to change direction.
Please close an issue if your question is resolved. We'll eventually come through and close them with a note to comment if that's in error.
from rclcpp.
Related Issues (20)
- Parameter service behavior is inconsistent with the documentation of rcl_interfaces HOT 9
- Lifecycle destructor calls shutdown while in shuttingdown intermediate state HOT 45
- Backport PR2063 to Humble for Windows HOT 2
- Executor callbacks are no longer in a predictable order HOT 25
- '/clock' Topic cannot change each loop step time from simulation time HOT 10
- Program exits with code -11 when using async_send_request to set parameters in ROS 2 C++ client HOT 1
- Timer callbacks can be delayed when using simulation time HOT 4
- Possible regression in rcl preshutdown callbacks - context invalid? HOT 11
- Shutdown transition on base lifecycle node dtor may lead to segaults on subclass-registered shutdown callback HOT 6
- `on_shutdown` callback not called when `shutdown` transition is triggered on dtor HOT 2
- ABI/API Compliance Checker in github workflow HOT 2
- [rclcpp] C++ lib leaking `rclcpp::Node()` can cause segfaults at `dlclose()` HOT 3
- Feature Request: Dynamic Type Handling for Generic Subscriptions HOT 15
- Action: rclcpp_action::Client goal response and feedback order not in send order HOT 5
- EventsExecutor doesn't support rcl guard conditions HOT 3
- Retrieving(get_parameter()) value of parameter of type std::vector<int> won't build HOT 3
- :farmer: `test_client_common` and `test_service` failing in Rolling and Jazzy connext nightlies HOT 2
- Issue with RCLCPP THROTTLE logging in the plugin based approach HOT 4
- :farmer: connext test regressions in `test_subscription_topic_statistics` HOT 8
- Double spin required since 28.2.0 HOT 20
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rclcpp.