This is also somewhat relevant to something I've been playing around
with. Nothing particularly novel, just a set of interfaces for exporting
unixy filsystems. It would be nice if I could get a union back (with
variants for directory vs. regular file) when doing something like open.
But, this means breaking pipelining, which is especially bad when you're
doing something equivalent to "cd foo/bar/baz/quux" and each path
component is its own call. So right now I've just got files and
directories being interfaces, and the walk() method returns a supertype
of both, which I then downcast to a directory, relying on errors to
catch me along the way if I try to walk into something that's not a
directory.

This works, but with the union solution I could retain some of the
type safety -- I wouldn't need to do an arbitrary downcast at least.

Throwing an exception seems like the right thing.

It occurs to me that you could actually use this to pipeline calls when
you *don't* know which variant will be returned, just by making the
appropriate calls to each variant and relying on the fact that at most
one of them will succeed.

Quoting 'Kenton Varda' via Cap'n Proto (2017-05-31 13:58:09)
>    Hi Johannes,
>    Thanks for the feedback.
>    I'm curious: In your use case, does the caller somehow know in advance
>    when getValue() is going to return an interface, thus allowing
>    pipelining? If so, would it make sense to have a separate method, e.g.
>    getInterface(), for that case, which just returns the interface without
>    the union, thus allowing pipelining today? Or if the caller does not
>    know in advance, then what would you like the behavior to be if the
>    caller makes a pipelined request but the result ends up not being an
>    interface? I guess the pipelined call should throw an exception?
>    -Kenton
>
>    On Wed, May 31, 2017 at 2:00 AM, Johannes Zeppenfeld
>    <[1]zeppe...@gmail.com> wrote:
>
>    Hi Kenton,
>    I'm reviving this thread because I've just had the same wish - to be
>    able to pipeline a union access. I have a type-erased interface Getter
>    that can return its value through a union struct. The returned value
>    could be either a builtin type, a struct or an interface:
>    interface MyInterface {
>    � myFunction @0 ();
>    }
>    struct Any {
>    � union {
>    �  invalid @0 :Void;
>    �  uint32 @1 :UInt32;
>    �  myInterface @2 :MyInterface;
>    �  # etc...
>    � }
>    }
>    interface Getter {
>    � getValue @0 () -> (value :Any);
>    }
>    Given a Getter and wanting to create the associated MyInterface client,
>    I currently need to do two round trips:
>    MyInterface::Client myInterface = getter.getValueRequest().send().then(
>    �  [](capnp::Response<Getter::GetValueResults> &&response)
>    �  -> MyInterface::Client {
>    �  �  return response.getValue().getMyInterface();
>    �  }
>    );
>    It would be a welcome optimization (both performance-wise and
>    boilerplate-wise) to be able to pipeline this:
>    MyInterface::Client myInterface = getter.getValueRequest().send()
>    �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �
>    .getValue().getMyInterface();
>    Just to add another voice to those desiring this feature :)
>    Thanks for your work on this amazing library!
>    Johannes
>
>      --
>      You received this message because you are subscribed to the Google
>      Groups "Cap'n Proto" group.
>      To unsubscribe from this group and stop receiving emails from it,
>      send an email to [2]capnproto+unsubscr...@googlegroups.com.
>      Visit this group at [3]https://groups.google.com/group/capnproto.
>
>    --
>    You received this message because you are subscribed to the Google
>    Groups "Cap'n Proto" group.
>    To unsubscribe from this group and stop receiving emails from it, send
>    an email to [4]capnproto+unsubscr...@googlegroups.com.
>    Visit this group at [5]https://groups.google.com/group/capnproto.
>
> Verweise
>
>    1. mailto:zeppe...@gmail.com
>    2. mailto:capnproto+unsubscr...@googlegroups.com
>    3. https://groups.google.com/group/capnproto
>    4. mailto:capnproto+unsubscr...@googlegroups.com
>    5. https://groups.google.com/group/capnproto

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to capnproto+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.

Attachment: signature.asc
Description: signature

Reply via email to