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

Use generics in globalsearch #1134

Open
exaV opened this issue Jun 25, 2024 · 2 comments
Open

Use generics in globalsearch #1134

exaV opened this issue Jun 25, 2024 · 2 comments

Comments

@exaV
Copy link
Contributor

exaV commented Jun 25, 2024

globalSearch currently returns a wildcard which always requires a cast afterwards, even though the return type is known for each SearchScope.

List<?> projects = gitLabApi.getSearchApi().globalSearch(SearchScope.PROJECTS, "text-to-search-for");

Ideally we would have a generic return type, based on SearchScope:

List<Project> projects = gitLabApi.getSearchApi().globalSearch(SearchScope.PROJECTS, "text-to-search-for")

SearchScope is currently defined as an enum which makes it impossible to use generics. We could convert it to class with static members to be able to use the same syntax and profit from generics.

   // with this definition the above usage of globalSearch compiles:

    public <T> Pager<T> globalSearch(SearchScope<T> scope, String search, int itemsPerPage) {
        // ...
        switch (scope) {
            case BLOBS:
                return (new Pager<>(this, scope.getResultType(), itemsPerPage, formData.asMap(), "search"));
         // ...
       }
    }

    public static class SearchScope<T> {
        private SearchScope(Class<T> resultType, String jsonName) {
        }
        
        public static final SearchScope<Project> PROJECTS = new SearchScope<>(Project.class, "projects");
        public static final SearchScope<SearchBlob> BLOBS = new SearchScope<>(SearchBlob.class, "blobs");
        
       // JsonCreator, JsonValue and ToString can be implemented using the `jsonName` field
    }

This would be a breaking change because code will have to be recompiled, although there should be no changes necessary on the users side.

@exaV
Copy link
Contributor Author

exaV commented Jun 25, 2024

Let me know if you'd like a PR for that

@jmini
Copy link
Collaborator

jmini commented Jul 1, 2024

I think the change is a good idea.

About the breaking change, if this works for you, maybe we do this only on the 6.x branch.

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
@jmini @exaV and others