Generate definition classes for inlined objects

[hanny24]

This PR bring support for generation of definition classes for objects that are inlined (they are defined with some other object definition). Current behavior is not to generate any definition class and just just io.circe.Json (scala). This PR significantly improves current situation.

Generated definitions for those classes are placed into a companion object. Name of a class is derived from a property for which the class was derived for. Please see a test if this is not clear.

A similar approach can be used for enums that are not defined on their own. Currently we use String. I plan to implement this as well, but in a separate PR to keep this one small.

Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

• I acknowledge that all my contributions will be made under the project's license.

[hanny24]

cc @blast-hardcheese

[blast-hardcheese]

@hanny24 Definitely on my radar for the new week, I didn't have time to look over the weekend. From what I've seen so far, this strategy gets us closer to object deduplicaton as well, which I'm particularly interested in. Thanks for you work so far 😄

[blast-hardcheese]

Some comments after an initial pass. I still haven't run it, but I'd like to say again that this is quite solid work.

[blast-hardcheese]

I see that fromModel calls prepareProperties which calls fromModel again. I presume this means that arbitrarily nested literals are supported. To this end, would you mind adding a runtime test (not a structure test) that ensures that the following compiles:

definitions:
  First:
    type: object
    properties:
      Second:
        type: object
        properties:
          Third:
            type: object
            properties:
              Fourth:
                type: string

I would presume that each nested object would further have other types nested inside, but ensuring that the type references are maintained would be very useful to know. I expect that test wouldn't work in Java, so we'll likely need to do some other work on our side to port what you've done over, but for the time being I believe it'll just be handled as the equivalent of a JSON literal (probably Object), so that should still compile.

[hanny24]

That's exactly right! References are maintained by the use of full names with companion objects. Maybe take a look at the new test that I added. It should make it clear.

[blast-hardcheese]

please just

typeNames.tail.map(Term.Name.apply _)
  .foldLeft[Term.Ref](Term.Name(typeNames.head))(Term.Select.apply _)

this is super difficult to read as it is currently.

[hanny24]

But this is a different thing:) First of all, we generate Type, not a Term. This operation is used to convert (non-empty) list of identifiers to a Type:

• if a list has single element, regular Type.Name is used
• for any other list we must generate Type.Select, that takes Term.Ref as first argument, and Type.Name as second.

For example, given List(A,B,C) it gives you a type of A.B.C. This is used for recursively nested structures.

One alternative would be:

val result = typeNames match {
   case NonEmptyList(head, Nil) =>
       Type.Name(head)
   case NonEmptyList(head, tail) =>
       val selectors = (head :: tail.dropRight(1)).map(Term.Name(_))
       Type.Select(selectors.reduceLeft[Term.Ref](Term.Select(_,_)), Type.Name(tail.last))
}

but I'm not sure it's any better.

[blast-hardcheese]

Oh, you're right, I didn't notice -- I also forgot about that nuance of needing a stable identifier when constructing a Type.Select.

A slightly different approach to what you have there, maybe?

val tpe = Type.Name(typeNames.last)
val names = typeNames.init.map(Term.Name.apply _)

names match {
  case Nil => tpe
  case x :: xs =>
    val term = xs.foldLeft[Term.Ref](x)(Term.Select.apply _)
    Type.Select(term, tpe)
}

[hanny24]

Seems good to me. Changed.

[hanny24]

Are there any other concerns? If not, I can squash all the changes into single commit.

[blast-hardcheese]

Thank you for your patience here, @hanny24. This looks good. I try to trend away from squash to permit git bisect to be used.

[blast-hardcheese]

I'll merge whenever you say this branch is ready to be merged. If you'd like to restructure the commits in any way (atomic, etc) feel free.

[hanny24]

It's ready to be merged now. Thanks!

[blast-hardcheese]

Thank you! This is really exciting!

[sledorze]

Indeed, with third party APIs that's really welcome.
Looking forward for anonymous enum support too..
btw @hanny24, is this tracked somewhere?

[hanny24]

We do now: #370