Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Currently the Resources class is used to dump everything loosely related to the protobuf Resource as member methods.
As a result Resources has a large amount of utility methods that are not related to the Resources abstraction.
Examples:
This returns a protobuf Resource and not Resources.
static Try<Resource> parse( const std::string& name, const std::string& value, const std::string& role);
This only looks at the protobuf too.
static bool isPersistentVolume(const Resource& resource);
This makes it hard to name and distinguish similar methods which work at different abstraction levels (see the parse(text, role) function below).
It would be way simpler to have them as namespaced free-standing functions.
namespace mesos {
// Methods for the protobuf `Resource`.
namespace resource {
Try<Resource> parse(
const std::string& name,
const std::string& value,
const std::string& role);
bool isPersistentVolume(const Resource& resource);
// Now I can add a `parse` method for multiple resources but at the `Resource` level.
Try<vector<Resource>> parse(
const std::string& text,
const std::string& defaultRole = "*");
}
// Methods for the `Resources` abstraction.
namespace resources {
...
}
}
Static member methods of Resources are still fine if they directly pertain to the Resources abstraction itself and we can use the private members/methods when useful.
e.g., Resources::flatten() uses the internal validation-free `add` method as opposed to `+=` to accumulate resource objects
Try<Resources> flatten(
const std::string& role,
const Option<Resource::ReservationInfo>& reservation = None()) const;
Attachments
Issue Links
- is related to
-
-
- Accepted
-