Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor thrift type #73

Merged
merged 11 commits into from Nov 8, 2016

Conversation

benjamin-bader
Copy link
Collaborator

This major refactoring fixes #66 and #69.

As discussed in the latter, Named goes away, and is merged in with ThriftType. ThriftType is a branchy hierarchy, and many of its elements share common structure that isn't easily expressed via direct inheritance. To that end, the new UserElement interface captures that commonality, and UserElementMixin encapsulates the logic; various types and components can implement the former by containing the latter.

Builders also get a proper refactoring with the introduction of inheritance and lots of generics garbage to make a nice API.

This is a pretty big change, though (hopefully) transparent to consumers; I'd appreciate eyeballs or, even better, testing from @hzsweers, @naturalwarren , @seanabraham, and any other folks who see this and are interested.

@benjamin-bader benjamin-bader added this to the 0.4.0 milestone Oct 29, 2016
package com.microsoft.thrifty.schema;

public abstract class NewThriftType {
public static final BuiltinThriftType BOOL = new BuiltinThriftType("bool");
Copy link
Contributor

Choose a reason for hiding this comment

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

Could these be enums instead?

/**
* Gets a value indicating whether the element contains non-empty Javadoc.
*/
boolean hasJavadoc();
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems kind of necessary. How about just using nullability on documentation() to indicate presence?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The particulars are lost to the mists of time; I think it was safer/more convenient to assume that javadoc() would never return null.

ns = program.namespaces().get(NamespaceScope.ALL);
}

if (ns == null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This feels a little awkward. Most cases for us, we actually just error if there's no namespace. Just returning null would be nice in that it would fail faster or in a more obvious way anyway

@@ -12,24 +12,24 @@ public boolean isBuiltin() {

@Override
public <T> T accept(Visitor<T> visitor) {
if (this == NewThriftType.BOOL) {
if (this.equals(NewThriftType.BOOL)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Following up the enum comment elsewhere, this is a great reason why :)

import com.microsoft.thrifty.schema.parser.StructElement;

public class NewStructType extends UserType {

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: double blank lines


@Override
public int hashCode() {
return Objects.hash(super.hashCode(), mixin, program);
Copy link
Contributor

Choose a reason for hiding this comment

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

nice

element.name(),
element.location(),
element.documentation(),
null); // No annotations allowed on Thrift constants
Copy link
Contributor

Choose a reason for hiding this comment

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

Make sure to add @Nullable onto the parameter

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hm, thought that it was there?

import com.google.common.collect.ImmutableMap;
import com.microsoft.thrifty.schema.parser.EnumMemberElement;

public class EnumMember implements UserElement {
Copy link
Contributor

Choose a reason for hiding this comment

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

Documentation

return false;
>>>>>>> Totally broken, but... Builders! Types! Change!
Copy link
Contributor

Choose a reason for hiding this comment

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

Whoops

@@ -430,20 +436,14 @@ ThriftType resolveType(TypeElement type) {
}

/**
* Looks up a {@link Named} symbol from a given name, possibly qualified.
* Deprecated.
*/
@Nullable
Copy link
Contributor

Choose a reason for hiding this comment

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

Add @Deprecated

@@ -55,6 +55,8 @@ void validate(Linker linker) {
if (oldType.equals(BuiltinThriftType.VOID)) {
linker.addError(location(), "Cannot declare a typedef of void");
}

// Typedef cycles are validated during linking
Copy link
Contributor

Choose a reason for hiding this comment

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

Might want to expand on this a bit, not really clear to me currently

@benjamin-bader benjamin-bader modified the milestones: 0.3.0, 0.4.0 Oct 31, 2016
@benjamin-bader
Copy link
Collaborator Author

I'm running this branch in one of our apps now; so far, so good. I've uploaded this as 0.3.0-SNAPSHOT, so it will be easy to play with while I make sure this is baked.

I intend to leave this PR open for the week. If no problems surface, and I don't hear of any major issues from folks here, I'll land this and prepare a release next week.

@yfrancis
Copy link

@benjamin-bader I've set aside some time to test this tomorrow. High level changes look good.

@naturalwarren
Copy link
Contributor

@benjamin-bader, @hzsweers and I are going to bump our Thrift code generator onto this change. Will update you with the results. This code generator creates hundreds of models and services.

@yfrancis
Copy link

yfrancis commented Nov 3, 2016

@benjamin-bader just verified that the generator output for our thrift projects is identical to the previous release, and correct. 👍

@naturalwarren
Copy link
Contributor

naturalwarren commented Nov 4, 2016

Ben I'm not able to pull these changes. Even doing a fresh clone of this repository, fetching all, and checking out refactor-thrift-type I can't find the branch.

git clone https://github.com/Microsoft/thrifty.git
git fetch --all
git checkout refactor-thrift-type
error: pathspec 'refactor-thrift-type' did not match any file(s) known to git.

@benjamin-bader
Copy link
Collaborator Author

@naturalwarren that's because the branch is in my own fork - replace microsoft with benjamin-bader.

@benjamin-bader
Copy link
Collaborator Author

In fact, @naturalwarren, here are the commands you can use:

git checkout -b benjamin-bader-refactor-thrift-type master
git pull https://github.com/benjamin-bader/thrifty.git refactor-thrift-type

@benjamin-bader
Copy link
Collaborator Author

OK, this has been baking for a little while and seems stable - landing now and releasing shortly.

Thanks to everyone who test-drove these changes!

@benjamin-bader benjamin-bader merged commit fa6dea0 into microsoft:master Nov 8, 2016
@benjamin-bader benjamin-bader deleted the refactor-thrift-type branch November 10, 2016 19:50
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.

Can't disambiguate between similar-enough imported enum constants
5 participants