Type/trait application algorithm


#1

I was wondering if other parser/code generator implementers has some words of wisdom about implementing code to apply resource types and traits to resources and method.

The spec is silent on the topic of collisions and precedence, but it seems that what makes the most sense is for say in a method hierarchy scalar properties having precedence over trait scalar properties and non-scalar properties being merged. Thus, the method is a specialization of the trait.

Similarly, the later or right most trait on a method should have high precedence, and method traits have higher precedence than resource traits.

This is simple enough to implement by say merging traits into the method in reversed precedence other ensuring that existing scalar properties are not overwritten.

The problem arrises when one tries to implement optional properties. When they are involved the method is not so much seen as a specialization of the traits, as the optional properties depend on values in the method. Implementing optional properties works best by merging the trait into the method and checking for the property existence to determine whether to apply a portion of the trait. If you have multiple traits you have to evaluate them from resource traits to method traits from left to right, as later traits may depend on keys created by earlier traits to be applied. But evaluating from earliest to latest is tricky. You want later trait scalars to override previous trait scalars, but not the method scalars.

Not sure if I was clear, but thoughts?


#2

I’m not sure how this is interally implemented by the RAML parser (or defined by the spec) but I would assume that if you override a method, then you lose all the previous signature of parameters. What matters (how I would expect RAML to work) is to only take the latest definition. I probably misunderstood your question but anyways just my 2 cents :).


#3

Hi, this is something we missed on RAML 0.8. We are documenting it the way we though about it and implemented it in the reference parsers.

RAML 1.0 will include a disambiguation about this. Thanks for reporting it.

https://github.com/raml-org/raml-spec/issues/83