You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 8, 2024. It is now read-only.
In light of recent PR's (i.e. #183#184#185#193 to name a few) a discussion point has been raised. Do we want to make such classes internal, and which classes should be interna?
Originally, the idea was that only classes that implement the interface as public, and all other classes are considered implementation specific and are internal to the module to make the module safer.
However, a valid point was raised, namely that making all classes internal does somewhat decrease extendibility of classes. (A question was also raised about which classes should be final or not but that is another discussion)
At the moment I prefer having only the classes that implement the interface be public. Perhaps it is best to go through the modules one by one and make classes public sparingly if we conclude that it could be used by another module as well, for instance a future module which builds upon a module or does something similar to a module. The Filter classes in the filter package in the jimple-library-usage-graph module for instance could be public.
The text was updated successfully, but these errors were encountered:
In light of recent PR's (i.e. #183 #184 #185 #193 to name a few) a discussion point has been raised. Do we want to make such classes internal, and which classes should be interna?
Originally, the idea was that only classes that implement the interface as public, and all other classes are considered implementation specific and are internal to the module to make the module safer.
However, a valid point was raised, namely that making all classes internal does somewhat decrease extendibility of classes. (A question was also raised about which classes should be final or not but that is another discussion)
At the moment I prefer having only the classes that implement the interface be public. Perhaps it is best to go through the modules one by one and make classes public sparingly if we conclude that it could be used by another module as well, for instance a future module which builds upon a module or does something similar to a module. The
Filter
classes in thefilter
package in thejimple-library-usage-graph
module for instance could be public.The text was updated successfully, but these errors were encountered: