Feature #21
Provide a visitor mechanism for flusspferd::value
| Status: | Assigned | Start: | 03/30/2009 | |
| Priority: | Normal | Due date: | ||
| Assigned to: |  Aristid Breitkreuz |
% Done: | 0% |
|
| Category: | C++-API | |||
| Target version: | 0.10 | |||
Description
flusspferd::value has a lot of is_foo and get_foo functions that would have to be tested in generic cases.
Proposed solution:
A visitor class has to implement the result_of protocol, namely provide a typedef result_type (which can be void).
apply_visitor (which should be added to flusspferd) then takes a visitor as argument and calls the appropriate operator()(T const &)
of the vistior.
Related issues
| related to Feature #136 | Easier (or make possible) to extend detail::convert for user-defined types | New | 10/23/2009 | ||
| blocked by Feature #12 | Evaluate conversion API | Assigned | 03/29/2009 |
History
Updated by Aristid Breitkreuz 528 days ago
- Status changed from New to Feedback
How should this cover the cases where
- the is_* functions are ambiguous,
- there are relevant subclasses, like array or function for object and
- especially the cases of null and void?
Updated by Aristid Breitkreuz 299 days ago
- Status changed from Feedback to Assigned
- Assigned to set to Aristid Breitkreuz
Pending the conversion overhaul, I'd like to see roughly the following API:
// assumption: MyClass1 and MyClass2 derive from native_object_base
struct visitor {
typedef ... result_type;
typedef boost::mpl::vector4<int, object, MyClass1, MyClass2> allowed_types;
result_type operator()(int) {
...
}
result_type operator()(object const &) {
...
}
result_type operator()(MyClass1 &) {
...
}
result_type operator()(MyClass2 &) {
...
}
};