search

smithy-lang / smithy-dafny

Apache License 2.0
10 stars 8 forks source link

Align need for orphaned shape generation better with Smithy code generation recommendations/idioms #627

Open robin-aws opened 1 month ago

robin-aws commented 1 month ago

Splitting this off from #622, which is about testing for the current state better, whereas this issue is about improving the current state.

Local services need to generate code for shapes not in the service closure for at least two different reasons:

  1. The config shape for a local service isn't directly connected to the service, only through the @localService$config member.
  2. Interceptors like the DB ESDK need configuration structures to be generated for shapes that are completely disconnected from any service, mainly because the interceptor concept is not yet modeled in a local service.

smithy-dafny generally generates code for all shapes in a namespace to get around this, but this can be surprising and makes it harder to re-use logic from other smithy-<lang> code generators.

Being able to generate just types from shapes without a dummy service attached is a very common Smithy feature request, and a general feature may land in the future we can use here.

texastony commented 1 month ago

Note: in the meantime, it would be really Groovy if Smithy Danfy's various code generators could consolidate on the same shape selection logic.

That is difficult, but would be Groovy.

robin-aws commented 1 month ago

FYI the standard solution for orphaned shapes is to add dummy operations to bring them into the service closure. That's probably our best option until Smithy itself broadly supports a proper feature for adding shapes to the closure, or "types" code generation that isn't driven by the closure.

texastony commented 1 month ago

That is not an acceptable solution, in our use case, at least on it's own.

Because that would add Dummy operations to our public interfaces.

That will not earn customer trust.

texastony commented 1 month ago

We could have some silly trait that comes back and deletes the dummy operations... But... I'd rather us refactor to have a static create service operation that takes the service config as an input.

If we had a trait/member on the local service trait, or some other indication, that the operation is used to create the local service, along with additional traits for references/resources, we could actually just model local service and resource creation.

Finally, if we refactor the models to ensure that all of a service's errors are listed on the service, we have entirely removed the currently identified orphaned shapes.