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

"cannot reduce visibility" of an inherited method in an inner class #4583

Closed
StanLepunK opened this Issue Jul 23, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@StanLepunK

StanLepunK commented Jul 23, 2016

When we use interface, Processing display an error ''''Cannot reduce the visibility of the inherited method...```` happyness the sketch run good. I use the example to show this error message https://processing.org/reference/implements.html
capture d ecran 2016-07-23 a 17 12 20

@benfry benfry changed the title from weird error message with the interface to "cannot reduce visibility" of an inherited method in an inner class Jul 28, 2016

@benfry benfry added the preprocessor label Jul 28, 2016

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jul 28, 2016

Member

As a workaround, add public to the different versions of move() (and display() for that matter).

Member

benfry commented Jul 28, 2016

As a workaround, add public to the different versions of move() (and display() for that matter).

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Jul 29, 2016

Contributor

@benfry Is this code supposed to run? Adding public to methods in inner classes is not a feature we support. Rather it's caused by "dumbness" of the method regexp, which adds public to all void methods. If you change return type to something else then void it won't work. I'd mark this as an enhancement.

Contributor

JakubValtar commented Jul 29, 2016

@benfry Is this code supposed to run? Adding public to methods in inner classes is not a feature we support. Rather it's caused by "dumbness" of the method regexp, which adds public to all void methods. If you change return type to something else then void it won't work. I'd mark this as an enhancement.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jul 29, 2016

Member

@JakubValtar The problem is that public is being added to some methods not others... So in this case, it appears that move() inside Dot has public added, but the same isn't happening in CircleDot and SquareDot.

Not sure what you mean re: return types changing—I don't see that in the code here.

Member

benfry commented Jul 29, 2016

@JakubValtar The problem is that public is being added to some methods not others... So in this case, it appears that move() inside Dot has public added, but the same isn't happening in CircleDot and SquareDot.

Not sure what you mean re: return types changing—I don't see that in the code here.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Jul 29, 2016

Contributor

@benfry Ah, sorry about the return type. I thought about a wrong regexp.

Is the preprocessor supposed to add public to all methods without a visibility modifier? Problem here is that the error checker leaves inner classes alone, while the old preprocessor goes inside.

Should I modify the error checker to visit inner classes when adding public? Right now it adds it only to top-level methods.

Contributor

JakubValtar commented Jul 29, 2016

@benfry Ah, sorry about the return type. I thought about a wrong regexp.

Is the preprocessor supposed to add public to all methods without a visibility modifier? Problem here is that the error checker leaves inner classes alone, while the old preprocessor goes inside.

Should I modify the error checker to visit inner classes when adding public? Right now it adds it only to top-level methods.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jul 29, 2016

Member

Yeah, if that's what we were doing before, by all means.

Member

benfry commented Jul 29, 2016

Yeah, if that's what we were doing before, by all means.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Aug 1, 2016

Member

Fix incorporated for 3.1.3.

Member

benfry commented Aug 1, 2016

Fix incorporated for 3.1.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment