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

Insure all public methods are overridden in interface; move interfaces to view package #631

Merged
merged 6 commits into from
Oct 27, 2017

Conversation

JordanMartinez
Copy link
Contributor

@JordanMartinez JordanMartinez commented Oct 27, 2017

TextEditingArea and its interfaces were moved back to the view package because it seemed more appropriate for them to be there than the model package, where they seemed to add unnecessary bloat.

Also, since #630 refers a developer to the interfaces despite some of the public methods in GenericStyledArea not being declared or documented in TextEditingArea or one of its interfaces, these methods are now declared and documented in those places and overridden in GenericStyledArea.

Since two event classes were already in the util package, and a third event class was still in the view package, these were moved to a new event package where it seemed more logical to put them there and also removes a little bloat in the view package. This leaves the util package open for additional utility classes in the future.

Lastly, _position() comes from #213 but has never been renamed to distinguish its functionality from position(). Since it only calls navigator.position(), which is itself confusing due to the other "navigators" that appear throughout the code or its dependencies, this was renamed to a clearer name. I also removed the middle-man-like method since it's only usage is in currentLine().

@JordanMartinez
Copy link
Contributor Author

Still... part of me wants to put the interfaces into an api package or something because their names cause them to appear throughout the package in an alphabetically-sorted view rather than next to one another, which is more appropriate due to their similar purposes. These could be renamed to something else, but that seems to make the names confusing. For example, I added the prefix "Area" but it makes them rather long (e.g. "AreaNavigationActions.SelectionPolicy"). If one were to place them into TextEditingArea as subinterfaces, then they do not appear in my IDE's project window (not sure how other IDEs render these).

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.

1 participant