You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Meng Zhu (JIRA)" <ji...@apache.org> on 2019/02/28 03:37:00 UTC

[jira] [Assigned] (MESOS-7124) Replace monadic type get() functions with operator*

     [ https://issues.apache.org/jira/browse/MESOS-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Meng Zhu reassigned MESOS-7124:
-------------------------------

    Assignee: Meng Zhu

> Replace monadic type get() functions with operator*
> ---------------------------------------------------
>
>                 Key: MESOS-7124
>                 URL: https://issues.apache.org/jira/browse/MESOS-7124
>             Project: Mesos
>          Issue Type: Improvement
>          Components: libprocess, stout
>            Reporter: Benjamin Bannier
>            Assignee: Meng Zhu
>            Priority: Major
>              Labels: tech-debt
>
> In MESOS-2757 we introduced {{T* operator->}} for {{Option}}, {{Future}} and {{Try}}. This provided a convenient short-hand for existing member functions {{T& get}} providing identical functionality.
> To finalize the work of MESOS-2757 we should replace the existing {{T& get()}} member functions with functions {{T& operator*}}.
> This is desirable as having both {{operator->}} and {{get}} in the code base at the same time lures developers into using the old-style {{get}} instead of {{operator->}} where it is not needed, e.g.,
> {code}
> m.get().fun();
> {code}
> instead of
> {code}
> m->fun();
> {code}
> We still require the functionality of {{get}} to directly access the contained value, but the current API unnecessarily conflates two (at least from a usage perspective) unrelated aspects; in these instances, we should use an {{operator*}} instead,
> {code}
> void f(const T&);
>     
> Try<T> m = ..;
> f(*m); // instead of: f(m.get());
> {code}
> Using {{operator*}} in these instances makes it much less likely that users would use it in instances when they wanted to call functions of the wrapped value, i.e.,
> {code}
> m->fun();
> {code}
> appears more natural than
> {code}
> (*m).fun();
> {code}
>     
> Note that this proposed change is in line with the interface of {{std::optional}}. Also, {{std::shared_ptr}}'s {{get}} is a useful function and implements an unrelated interface: it surfaces the wrapped pointer as opposed to its {{operator*}} which dereferences the wrapped pointer. Similarly, our current {{get}} also produce values, and are unrelated to {{std::shared_ptr}}'s {{get}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)