Open live1206 opened 3 months ago
cc @tadelesh @m-nash @ArcturusZhang
The original design goal for this was we would have an @scope decorator which simply modified the scope of any given item.
I would imagine we could do @@scope(Service.op, "~csharp")
. Meaning the operation applies to everything but csharp.
If we handle this in .NET generator directly, the usage calculation in TCGC will miss this part and end into inaccurate usage. So, would like to still handle this in TCGC despite this requirement is only for .NET. Potentially, it could benefit the other languages.
Normally, a decorator could be applied to Type, to avoid the over complexity only apply it to Operation as needed now.
usage:
# "~" means exclude the target operation from the defined scope
@scope("~csharp")
op nameInService: void;
@scope("java")
op nameInService: void;
validation:
empty-scope
since there is no point to define an empty scopeis-in-use
if the operation itself is in use or the models/enums contained in the operation is in use, the scope change will potentially affect the use references
exclude-target-not-existed
if the target to be excluded does not exist in main.tsp
include-target-existed
if the target to be included already exists in main.tsp
include-target-not-declared
if the target to be included is not declared, the main usage of inclusion is within client.tsp
by adding some extra operation declarationeffect: the operation along with everything inside(we have validation to ensure everything inside is not referenced outside this operation) will be removed from the excluded language scopes, and the usage should be calculated correctly based on this.
Found https://github.com/Azure/typespec-azure-pr/issues/2732 regarding scope
of decorators in TCGC.
I think the proposal of @scope
decorator is identical to @exclude
and @include
with scopes, just need to extend the entity from Model
to Operation | Model
.
And now @exclude
and @include
are deprecated, because we think they can be replaced by @usage
and @access
. So, don't feel like adding a new @scope
decorator will be the approach we would take.
Another option raise from @ArcturusZhang is to use @convenientAPI
, TCGC has taken care of the Model usage. .NET SDK mgmt generator just needs to omit the operation if InputOperation.GenerateConvenienceMethod is false, same behavior as DPG
Found Azure/typespec-azure-pr#2732 regarding
scope
of decorators in TCGC. I think the proposal of@scope
decorator is identical to@exclude
and@include
with scopes, just need to extend the entity fromModel
toOperation | Model
. And now@exclude
and@include
are deprecated, because we think they can be replaced by@usage
and@access
. So, don't feel like adding a new@scope
decorator will be the approach we would take.Another option raise from @ArcturusZhang is to use
@convenientAPI
, TCGC has taken care of the Model usage. .NET SDK mgmt generator just needs to omit the operation if InputOperation.GenerateConvenienceMethod is false, same behavior as DPG
After clarification with @m-nash, the negation language scope is not implemented, but not abandoned.
The reason we need a new @scope
decorator and it can't be replaced by the existing deprecated @include
is because we can't define the behavior of @include
or @exclude
decorator with negation scope.
@live1206 would you be able to contribute a design and implementation for this? Thanks!
@live1206 would you be able to contribute a design and implementation for this? Thanks!
Sure, will add more details with what I have been doing.
Clear and concise description of the problem
For .NET SDK, we have requirement to remove certain operations, such as
Operations.list
should always be removed as duplicated within resource manager. Right now, the best approach we have is below, detailsBut this operation still exists, .NET SDK need to handle it specifically. Is it possible to remove this operation from TCGC result? for instance,
Or can we have a new decorator to remove an operation in TCGC?
Checklist