mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bannier (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-7124) Replace monadic type get() functions with operator*
Date Thu, 09 Mar 2017 13:10:38 GMT

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

Benjamin Bannier updated MESOS-7124:
------------------------------------
    Summary: Replace monadic type get() functions with operator*  (was: Replaced monadic type
get() functions with operator*)

> 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
>              Labels: newbie, 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
(v6.3.15#6346)

Mime
View raw message