Quoting Kenton Varda (2019-06-26 07:13:03)
> One thing that is part of that is making sure related declarations can
> be grouped together, so that they can easily be read and digested
> together, without scrolling back and forth. I'd say this is the main
> motivation for nested declarations -- they can live next to the field
> or method that references them, rather than far away at the global
> scope.
One interesting approach that came to my head: you could allow
definitions to be syntactically nested in the schema (as they are now),
but not actually live in separate namespaces, so the generated code
could still have a flat namespace. A bit non-intuitive, but otherwise
seems to combine the best of both worlds, and it wouldn't be hard for
the schema compiler to generate a clear and helpful error message in
the case of collisions of this sort.
> It's also the motivation for inlined method parameters and results,
> rather than requiring separate structs.
I'll grant there's a big readability drop in most cases with separate
structs; I'm not happy with the current trade-off, but I see the
argument.
> However, most of the multiple inheritance is to add persistence.
Furthermore, all of these are just declaring a one off interface like:
interface PersistentFoo extends (Foo, SystemPersistent) {}
Which is not used anywhere else in the schema, and has no methods of its
own nor any meaningful semantics except for adding persistence to
another interface.
I imagine the reason for all of these is just that (as I understand it),
the C++ implementation doesn't provide any way to export a capability
that implements disjoint interfaces -- you need to have a common
subtype. I think these interfaces are really C++ implementation detail
unnecessarily leaking back into the schema definitions, making them less
declarative.
I suspect there is a better solution to be found involving direct
support for exporting disjoint method sets. You can do this with
the Go implementation, but it's a little non-obvious; see:
https://github.com/capnproto/go-capnproto2/issues/86
..and:
https://github.com/zenhack/sandstorm-filesystem/blob/master/filesystem/local/local.go#L231-L249
> I also expect that there are features other that persistence which
> might be similarly orthogonal to business logic, which people will
> want the ability to mix-in in a similar way.
This is a plausible argument, but I am dubious of including features
with demonstrable downsides on the basis of somewhat vague, so far
purely hypothetical use cases.
-Ian
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/capnproto/156169027156.2272.8193064500905449301%40localhost.localdomain.
