On Thu, Jun 27, 2019 at 7:55 PM Ian Denhardt <[email protected]> wrote:
> 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.
>
Any particular code generator can also make this choice, although of course
it's possible the names won't be sufficiently unique if the author wasn't
thinking about them. Though in practice I bet such conflicts are rare
within a single schema file.
Maybe this calls for a new annotation $topLevelName("Blah") which will be
used by code generators in languages that don't support nesting. Perhaps
the Go and Haskell code generators could then default to putting all types
in the global scope, and if/when conflicts arise, this annotation can be
added to address it.
> I suspect there is a better solution to be found involving direct
> support for exporting disjoint method sets.
Isn't that still multiple inheritance, though? Wouldn't it be just as hard
to support it in this ad hoc way as it is to support it as a first-class
language feature?
-Kenton
--
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/CAJouXQkLft986Kmr_CGxPT2XRWX12aEj6QMr3UiWag3t-bJVAA%40mail.gmail.com.
