Skip to content

simplify union code generator and generated union code#22

Merged
ferozco merged 5 commits into
developfrom
me/simplify-unions
Jul 2, 2018
Merged

simplify union code generator and generated union code#22
ferozco merged 5 commits into
developfrom
me/simplify-unions

Conversation

@markelliot
Copy link
Copy Markdown
Contributor

No description provided.


assertThat(unionTypeStringExample).isEqualTo(stringExample);
assertThat(unionTypeSet).isEqualTo(ImmutableSet.of("item"));
assertThat(unionTypeInt).isEqualTo(5);
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so it turns out that when we added the ability to have a union over the same type this test (and the behavior more generally) became invalid

@JsonDeserialize(builder = Union.Builder.class)
@Generated("com.palantir.conjure.java.types.BeanGenerator")
@JsonInclude(JsonInclude.Include.NON_EMPTY)
private static final class Union {
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a bit of an alternative for simplifying the generated code further, we could:

  • drop this to just be a mutable class
  • skip using the Builder class and handle everything as nullable instead of optional

.addStatement("this.$1L = $1L", VALUE_FIELD_NAME)
private static TypeSpec generateUnionBean(TypeMapper typeMapper, UnionDefinition typeDef, String typePackage,
ClassName unionClass) {
return BeanGenerator.generateBeanTypeSpec(typeMapper, ObjectDefinition.builder()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you fix the whitespace here? it makes it a little hard to read

for (FieldDefinition def : fieldDefs) {
String getterName = BeanGenerator.asGetterName(def.getFieldName().get());
if (first) {
block.beginControlFlow("if ($1N.$2L().isPresent())", UNION_FIELD_NAME, getterName);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably worth calling out that we now support/fix support for unions with the same type

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

behavior between this code and existing code is the same, the tests I killed were invalid

@markelliot
Copy link
Copy Markdown
Contributor Author

happy to kill this/it's just a quick experiment, mostly pushed it as a thing to start a conversation around how we want to do unions. it's possible for us to cut more generated code than I've cut here at the cost of more generator code and maybe less immutable generated code.

@ferozco ferozco merged commit 36f4c95 into develop Jul 2, 2018
@ferozco ferozco deleted the me/simplify-unions branch July 2, 2018 05:42
@markelliot
Copy link
Copy Markdown
Contributor Author

@ferozco not actually sure we wanted to merge this/probably still worth a discussion...

@iamdanfox
Copy link
Copy Markdown
Contributor

iamdanfox commented Jul 2, 2018

TBH I'd prefer to only make changes like this when they are motivated by benchmarks or user requests. However, this doesn't change external facing APIs, so it's probably fine to just try it and see. Slight concerns:

  • Heap representation of a conjure union now contains O(variants) pointers (previously one pointer to polymorpic Base) because Union is full of optionals, where all but one is empty.
  • only one JsonUnwrapped annotation is necessary (fixed: Remove unnecessary @JsonUnwrapped constructor annotation #26)
  • keeping Optionals around internally seems unnecessary - why not just nullable fields?

@markelliot
Copy link
Copy Markdown
Contributor Author

cool yeah, i'm fine with throwing this away, it was a quick experiment to see if we could reduce overall amount of code, threw it up just as a discussion point

iamdanfox added a commit that referenced this pull request Jul 3, 2018
@ferozco ferozco mentioned this pull request Jul 18, 2018
ferozco added a commit that referenced this pull request Jul 18, 2018
Revert #22. Since it was originally just an experiment and it caused #44, I hope its ok. I am keen to open up the discussion on how implement unions, especially if we have some numbers around the performance of one approach vs. another
carterkozak pushed a commit to carterkozak/conjure-java that referenced this pull request Dec 24, 2018
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.

3 participants