You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@extendable marks a resource as client-implementable. At a minimum that changes the rules about backwards compatibility: with a non-extendable resource a service is free to add operations later, but if client implementations exist for an extendable resource, they will break. At a minimum we should implement this validation rule for @extendable as part of #315.
This issue is about whether we can in fact support adding operations by including a default implementation for them. I have a question mark on the issue title because I'm pessimistic: SOME target languages support this, for example Java allows default implementations of interfaces. But we haven't designed the codegen for this case and I suspect at least one language has us locked in already. It's also likely that supporting this would lead us to less idiomatic and user-friendly choices for extendable resources, so it might be better to just accept this tradeoff in the design of @extendable resources.
The text was updated successfully, but these errors were encountered:
Split off from #544.
@extendable
marks a resource as client-implementable. At a minimum that changes the rules about backwards compatibility: with a non-extendable resource a service is free to add operations later, but if client implementations exist for an extendable resource, they will break. At a minimum we should implement this validation rule for@extendable
as part of #315.This issue is about whether we can in fact support adding operations by including a default implementation for them. I have a question mark on the issue title because I'm pessimistic: SOME target languages support this, for example Java allows
default
implementations of interfaces. But we haven't designed the codegen for this case and I suspect at least one language has us locked in already. It's also likely that supporting this would lead us to less idiomatic and user-friendly choices for extendable resources, so it might be better to just accept this tradeoff in the design of@extendable
resources.The text was updated successfully, but these errors were encountered: