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

Provide static acessors in the ILog interface as an alternative to Platform #498

Merged
merged 1 commit into from
Jun 21, 2023

Conversation

laeubi
Copy link
Contributor

@laeubi laeubi commented Jun 14, 2023

Currently one obtains ILog either by injection/di or a static call to Platform.getLog(...)., but is is more semantic to only use ILog interface and also decreases the coupling of the code to a central singleton class.

This is similar to the recent changes in IPath and will also help in decreasing the need to call Platform.getXXX methods so we can easier adapt for changes here especially in the context of eclipse-equinox/equinox#253.

A next step would to to replace references, and possibly moving ILog to equinox common to reduce the amount of split package classes.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 14, 2023

Test Results

     30 files  ±0       30 suites  ±0   43m 11s ⏱️ - 1m 17s
2 380 tests ±0  2 379 ✔️ ±0  1 💤 ±0  0 ±0 
7 143 runs  ±0  7 139 ✔️ ±0  4 💤 ±0  0 ±0 

Results for commit 1431e56. ± Comparison against base commit a29e306.

♻️ This comment has been updated with latest results.

@HannesWell HannesWell changed the title Provide static acessors in the interface as an alternative to Platform Provide static acessors in the ILog interface as an alternative to Platform Jun 14, 2023
Copy link
Member

@HannesWell HannesWell left a comment

Choose a reason for hiding this comment

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

I like the overall idea.
This also reminds me of #33 and I think if we add two new API methods we should add another argument-less convenient method get() or ofContext() or alike.

@laeubi laeubi force-pushed the move_log_accessor_to_ilog branch from be93f2c to ee3e05c Compare June 15, 2023 05:41
@laeubi laeubi requested a review from HannesWell June 15, 2023 05:41
Copy link
Member

@HannesWell HannesWell left a comment

Choose a reason for hiding this comment

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

Looks good for me. Just a few minor remarks below.

Since the last time it was quite a controversial topic I think it would be good to get some more feedback from others.

@@ -922,7 +922,7 @@ public static long getStateStamp() {
* @since 3.0
*/
public static ILog getLog(Bundle bundle) {
Copy link
Member

Choose a reason for hiding this comment

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

I think a comment mentioning the new method would be good here and below.
Eventually this method should at least be deprecated.

@@ -132,4 +134,45 @@ default void error(String message) {
default void error(String message, Throwable throwable) {
log(new Status(IStatus.ERROR, getBundle().getSymbolicName(), message, throwable));
}

Copy link
Member

Choose a reason for hiding this comment

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

Not it that it really matters, but I have the impression that usually such static factories methods are added at the top of the file instead of the bottom.

@vogella
Copy link
Contributor

vogella commented Jun 20, 2023

LGTM

Currently one obtains ILog either by injection/di or a static call to
Platform.getLog(...)., but is is more semantic to only use ILog
interface and also decreases the coupling of the code to a central
singleton class.
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