# HG changeset patch # User Paul Boddie # Date 1670802300 -3600 # Node ID c24e354011ac85bb722de3caef677d88358ac414 # Parent c382ddaf6316dda0b03be58132d2b69630f6b9e4 Updated the roadmap, removing issues that are now resolved by the introduction of interface composition syntax and multiple input file processing. diff -r c382ddaf6316 -r c24e354011ac docs/wiki/Roadmap --- a/docs/wiki/Roadmap Sun Dec 11 23:57:07 2022 +0100 +++ b/docs/wiki/Roadmap Mon Dec 12 00:45:00 2022 +0100 @@ -29,26 +29,6 @@ parsing toolkit. [[http://www.dabeaz.com/ply/|PLY]] would be a potentially usable candidate. -== More Integrated Compound Interfaces == - -Having compound interfaces supported at the command level helps to avoid -difficult issues introduced by supporting them at the language level, but it -would arguably be more elegant to support them using a form of interface -inheritance, even though this introduces some awkward issues of its own. - -== Consolidation of Output Files == - -Currently, the `_interface.h`, `_interfaces.h` and `_interface_type.h` files -generated for compound interfaces are all created because individual -interface details are written incrementally to different output constructs, -and such constructs are most easily maintained using distinct output streams. -However, the details of the individual interfaces are readily available from -the processed command options. - -Thus, interface type information (`_interface.h` and `_interface_type.h`) -could be written out completely without involving the individual interface -code generation in the production of these files. - == More Abstract Type Handling == Types employed in interface descriptions are currently mostly propagated to