Recursive Data Types


#1

Will 1.0 make it possible to have recursive data types? Here’s an example:

  Count: integer
  Table:
    type: object
    properties:
      []:
        type: Data
  Data: Count | Table

Many languages have sum types, where it is common to define a type recursively. In my case, I’m trying to represent a C++ variant type at the REST level, which would require such a construction as above.

Slightly off-topic: while I was figuring out if this is legit construction, I couldn’t find a way to validate my 1.0 RAML spec. Do I have to trust the RAML code until there’s better tooling available? I’d be great if you guys could provide a web service or stand-alone tool enabling users to verify the integrity of the spec.


#2

Did you try the apiworkbench.com? MuleSoft developed a tool and provided it to the community. It has capabilities for 1.0 already, as well as 0.8.

Regarding the data type. Not sure if that is restricted, I would need to ask. :wink:


#3

Thanks for the tip regarding apiworkbench, that’s quite a nice implementation. (Too bad they don’t have a vim plugin.) It seems that recursive data types are currently not supported, as this simplified example shows:

  T: boolean | integer
  U: T | string

This fails with the following error:

Extending from types extending union types is not allowed

I double-checked with the spec. The section Inheritance Restrictions mentions:

You cannot inherit from types extending union types ( ex: you cannot extend from Pet if Pet = Dog | Cat )

Even though composition has nothing to with inheritance, it appears the example given conveys that composition of union types is not supported. This should be made clearer in the spec, and not convoluted with inheritance.

My next question is: why? In order to design composable data types, one naturally aggregates them into higher-level abstractions. Without composition, data types will remain of limited use with a few basic types and do not scale. Therefore, I advocate to remove this restriction from union types.


#4

Sure?

What do you expect to have from extending an “unioed-type” (for example: Pet = Dog | Cat) ?. It would be something like a “DogCatPet”?

Once a type is “unioned” it type can be ONE of its alternatives, but that’s it, ONLY ONE, no more. So, how could its child determine which of the possible “unioed” types of the parent really is it extending of?


#5

Hm, to best of what I see it is a clearly bug in the parser, U is not extending from T but is a union of T and string. Please file an issue in https://github.com/raml-org/raml-js-parser-2/issues if it is still reproducable with a latest parser

Regards,
Pavel