Date: Fri, 6 May 2022 18:36:27 -0400
On 5/6/2022 3:41 PM, Iain Sandoe via SG15 wrote:
> Another thing that I think would be helpful is to sketch out a non-trivial
> module (i.e with multiple partitions and at least one that is implementation)
> and then describe the source code TUs that would contribute to such a
> project..
>
> e.g. if there is code that the module-vendor does not wish to
> distribute, there might be private APIs that the module vendor does not
> even wish to be visible to the consumer of the module.
I think the idea is that the internal partitions could be used for a
pImpl pattern of sorts. It would allow that code to be changed without
changing the BMI of the module and forcing a recompile of everything
depending on that module.
However, creating a non-trivial module would be a good exercise. I have
given some thought to what VTK would look like if we used modules and
how this would work, but it is not much more than thinking about it at
this point.
-Bill
> Another thing that I think would be helpful is to sketch out a non-trivial
> module (i.e with multiple partitions and at least one that is implementation)
> and then describe the source code TUs that would contribute to such a
> project..
>
> e.g. if there is code that the module-vendor does not wish to
> distribute, there might be private APIs that the module vendor does not
> even wish to be visible to the consumer of the module.
I think the idea is that the internal partitions could be used for a
pImpl pattern of sorts. It would allow that code to be changed without
changing the BMI of the module and forcing a recompile of everything
depending on that module.
However, creating a non-trivial module would be a good exercise. I have
given some thought to what VTK would look like if we used modules and
how this would work, but it is not much more than thinking about it at
this point.
-Bill
Received on 2022-05-06 22:36:30