Sshirokov/336 transport #340
Conversation
- added `ITransport::makeMessage[Rx|Tx]Session` methods - added `ITransport::make[Request|Response][Rx|Tx]Session` methods Also: - added `libcyphal::UniquePtr` & `libcyphal::Expected` - added`transport::AnyError`
…essageRxTransfre` and `ServiceRxTransfer` types.
| public: | ||
| Factory() = delete; | ||
|
|
||
| CETL_NODISCARD static inline Expected<UniquePtr<ICanTransport>, FactoryError> make( |
There was a problem hiding this comment.
Why can't this be a freestanding function?
There was a problem hiding this comment.
My rationale was to avoid freestanding functions (which for my taste a bit "c-style"), but instead you know "encapsulate" them into some sort of entity (like this Factory). Also, IMHO if we apply such pattern everywhere then it will be easier for users to guess where to find a factory method, like always <correct_namespace>::Factory::make(...) something. But in general I'm totally good with essentially the same <correct_namespace>::makeSomething(...) approach.
Probably it's again my Swift habits - there are no namespaces in Swift, so any freestanding function is GLOBAL one, which is considered as bad design - so you nest such functions in some (sub)type as static one.
Please let me know if my rationale is not applicable for c++, or there are reasons to specifically go with freestanding alternative. Thanks!
There was a problem hiding this comment.
Yeah, I don't think it applies here; we should rather keep things simple and use a freestanding function.
There was a problem hiding this comment.
will fix this in the next pr
| public: | ||
| Factory() = delete; | ||
|
|
||
| CETL_NODISCARD static inline Expected<UniquePtr<ICanTransport>, FactoryError> make( |
There was a problem hiding this comment.
Yeah, I don't think it applies here; we should rather keep things simple and use a freestanding function.
ITransport,ICanTransport&IUpdTransportPayloadFragmentnow immutable;FragmentBufferis mutable span.