Skip to content

Conversation

hbina
Copy link

@hbina hbina commented Jan 26, 2021

  1. Enums can hold any value: boolean, strings, numbers...so just use JsonValue
  2. Items can point to Ref so wrap Schema inside ObjectOrReference
  3. Reorder ObjectOrReference because they are untagged, its better to check for Ref first

Signed-off-by: Hanif Ariffin hanif.ariffin.4326@gmail.com

1. Enums can hold any value: boolean, strings, numbers...so just use JsonValue
2. Items can point to Ref so wrap Schema inside ObjectOrReference
3. Reorder ObjectOrReference because they are untagged, its better to check for Ref first

Signed-off-by: Hanif Ariffin <hanif.ariffin.4326@gmail.com>
@bergmark
Copy link

Reorder ObjectOrReference because they are untagged, its better to check for Ref first

Is there a reason to keep ref_path in the "Objects" with this? My understanding of openapi is that $ref excludes the possibility of any other fields, if so i think it would make sense to

  • Drop ref_path from the structs that are used as Objects
  • Fail parsing if a ref is encountered along with other properties

The current situation is odd as I implemented support for refs in a tool and then noticed that all the holes i left for ObjectOrReference::Ref were unused :-) But just swapping it may leave another hole instead, with e.g. Schema:ref_path being unused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants