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 [email protected].
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.
