Will follow up if it needs to fit in Preview 1
Double check with @jianghaolu
Auto-gen makes it by design. If the boolean field has "is" as prefix, then do nothing. If no "is" prefix, add "is" for the field.
@brjohnstmsft Two options to address this:
For make search mode immutable, we can change the field to 'read-only' in swagger.
Then auto-gen will generate getSearchMode only.
Swagger does not support static field for object, so we cannot simply make it static (only in transform). Also, we don't think it is necessary to the field static. If we want it to be immutable, then mark it as 'read-only' in swagger.
@sima-zhu I don't understand this question:
@brjohnstmsft is there any special benefit to make it analyzer?
Did you mean abstract? If so, the benefit is that customers won't attempt to instantiate the class directly, which leads to serialization errors if they send a base class instance in a request.
@sima-zhu
Auto-gen makes it by design. If the boolean field has "is" as prefix, then do nothing. If no "is" prefix, add "is" for the field.
That's a bad design. 馃槈
I would rather not rename the properties to work around a bad codegen design choice, when the names we chose are (IMO) very clear. I'd suggest using transforms to fix this if that's what it takes.
@sima-zhu
- Suggester -- getSearchMode and setSearchMode should not be exposed, at least at an instance level. It certainly shouldn't be mutable. Ditto for SynonymMap's format property. In C#, these are static immutable properties.
- For make search mode immutable, we can change the field to 'read-only' in swagger.
Then auto-gen will generate getSearchMode only.- Swagger does not support static field for object, so we cannot simply make it static (only in transform). Also, we don't think it is necessary to the field static. If we want it to be immutable, then mark it as 'read-only' in swagger.
I don't think read-only is accurate in this case, since the parameters actually do need to be sent to the REST API. The issue is that these parameters only support one value, so it's redundant to require customers to send this value every time. The C# code generator solves this problem by emitting a static read-only property. I'm not too opinionated about how the Java codegen solves this problem, as long as it's solved, because customers shouldn't have to think about these parameters (at least until we add more values to them).
I realize we should never have exposed these parameters in the REST API until they had more than one possible value, but it's too late to fix that now.
For boolean naming: