Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Returning a proxy from dispatch #27

Closed
spectre-ns opened this issue Sep 13, 2022 · 3 comments
Closed

[Question] Returning a proxy from dispatch #27

spectre-ns opened this issue Sep 13, 2022 · 3 comments

Comments

@spectre-ns
Copy link

Would this be a valid implementation or is there some reason I would not want to do this?

    struct Draw : pro::dispatch<void(std::ostream&)> {
        template <class T>
        void operator()(const T& self, std::ostream& out) { self.Draw(out); }
    };
    
    struct Area : pro::dispatch<double()> {
        template <class T>
        double operator()(const T& self) { return self.Area(); }
    };

    struct Self;
    struct AreaFacade : pro::facade<Area> {};
    struct DrawFacade : pro::facade<Draw> {};
    struct DrawableFacade : pro::facade<Self, Area, Draw> {};
    
    struct Self : pro::dispatch<pro::proxy<AreaFacade>()> {
        template <class T>
        pro::proxy<AreaFacade> operator()(T& self) { return pro::make_proxy<AreaFacade>(std::move(self)); }
    };

Notice I'm converting a DrawableFacade to an AreaFacade in the self dispatch type. This would be an attempt to do something like a classic upcast I suppose where I have an implementation that needs only a subset of the current facade's available interface.

@spectre-ns spectre-ns changed the title Returning a proxy from dispatch [Question] Returning a proxy from dispatch Sep 13, 2022
@mingxwa
Copy link
Collaborator

mingxwa commented Sep 14, 2022

@spectre-ns The motivation is valid, but semantics of Self looks a bit weird. If Self is not intended to transfer the ownership of the value to the other proxy (e.g., no asynchronous operation required), maybe it would be more reasonable to return &self rather than pro::make_proxy<AreaFacade>(std::move(self)).

@spectre-ns
Copy link
Author

@mingxwa yes you are correct the ownership model here is weird. If I were going to implement this in the wild I would likely make the facade copyable to eliminate the move and prevent transfering ownership. The implicit move could be a gotcha when dispatching self then trying to continue to use that same proxy after the move.

@spectre-ns
Copy link
Author

I was mainly targeting the use case where I'm passing proxies around and I have an interface that is more abstract than my current proxy. In that case I would want to 'translate' to the more abstract version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants