-
Notifications
You must be signed in to change notification settings - Fork 54
Confusing AST for enum examples #734
Comments
I'm interested, in what way is this behavior a regression/bug? What is it breaking? Admittedly, this transformation is confusing, but I don't understand how it's incorrect. Does the emitted API Elements fail to represent the data structure given to drafter in MSON?
Also note that the output of drafter, API Elements, is by no means an Abstract Syntax Tree (AST) for API Blueprint. |
@tjanc I don't mean that it's a bug or regression. Actually you are right, it's confusing behaviour. |
We were toying with the idea of saying that samples/default are interpreted as fixed in API Elements by default. If I recall correctly, we dropped that mainly because of three reasons:
That said, I don't really see a reason why we shouldn't put the @pksunkara What's your take on this? |
Actually I can't understand your point. Do you mean that such AST could be interpreted without any context?
If I'm not mistaken this part is the same for enum with one element and enum example, so you need a bit of context to understand what is it.
Could you please explain your point a bit more?
What is second order types in this context? |
Suppose such doc:
Drafter generates such AST for samples section
It's logically correct: samples for string element is an array of strings.
Suppose such doc:
Drafter generates such AST for samples section:
I think
element: "enum"
is incorrect in this case. Samples for such enum should be strings from the set "free", "premium", but not a new enum type which contains single string element. So in my opinion correct sample should be something like:The text was updated successfully, but these errors were encountered: