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

ResultHandle getType() has different access level than the ResultType that gets passed back #170

Open
holly-cummins opened this issue Jan 4, 2024 · 4 comments

Comments

@holly-cummins
Copy link
Contributor

holly-cummins commented Jan 4, 2024

I just tripped over a little inconsistency in ResultHandle. The getResultType method is public:

    public ResultType getResultType() {
        return this.resultType;
    }

... but the ResultType class is package-private.

image

I'd submit a PR to either make the method package private or make the type public, but I wasn't sure which was preferable. Maybe there's a reason for it to be package private?

@dmlloyd
Copy link
Member

dmlloyd commented Jan 4, 2024

Given that ResultType is an enum (i.e. immutable and thus relatively foolproof), IMO it's probably OK to just make it public.

@holly-cummins
Copy link
Contributor Author

One reason to make the method package private (maybe, sorta) is that getType() is package private, and it's arguably the more useful of the two methods. So it might be strangely inconsistent to have getResultType public but not getType.

@dmlloyd
Copy link
Member

dmlloyd commented Jan 4, 2024

We could make that public too I think. At least I see no reason why not.

@Ladicek
Copy link
Contributor

Ladicek commented Jan 24, 2024

I don't think getResultType() is ever useful outside of Gizmo internals. I would make that method package-private, personally.

On the other hand, getType(), which is the "static" type of the value, that indeed can be useful, except the String representation is super user-unfriendly...

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

No branches or pull requests

3 participants