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
The ViewEvent system is pretty robust, but parts of it feel a little bit tacked on, or overly complicated. There are a number of changes that could be made to the system to slim it down, but maintain its robust nature.
Modify ViewEvent#getType() - This method should return a macro level type, instead of the micro level that currently is shared. Right now the list is thick, and a user might very well need multiple interactions to resolve a single task. Any situation where there is a isXXXXEvent() method that merges these types into a single boolean should also be a single type in ViewEvent#getType().
Add ViewEvent#getTypeSpecific() - Given that there are probably very good reasons to retain these split types, there should be an allowance for types to have subtypes, and there should be a method to get those. This will allow for all current functionality to be maintained, but gives more granularity and control for new, general, and veteran users of the library.
Convert ViewEvent to an abstract class with typed descendants instead of including everything in the same class - This is an alternative suggestion to the previous two steps, and arguably a better choice for SnapKit's long-term use. Right now the capabilities of SnapKit's event system are restricted to those included in the library, there is no way for a user to create a new type of ViewEvent and slot it into the system. Converting each of the types into their own class would use the core ability of Java to maintain these type systems, without relying on Enums and hardset classes that a future user cannot extend.
This one is a little more complicated than the last two, and would require a reworking of how the inheritance currently works. How I would do it is have the implementation (Cheerp vs Swing) as an object stored inside of the SnapKit environment itself (or if we must inside the event, but that is less good), and then let the inheritance of ViewEvent be all about the different types of ViewEvents. This then lets subtypes just be extensions of the children, which is more aligned with Java's general behaviour with such things. I believe it is also a more intuitive system for newcomers, as it also makes the system extensible for future purposes.
The above list will be modified as more improvements/changes are found.
The ViewEvent system is pretty robust, but parts of it feel a little bit tacked on, or overly complicated. There are a number of changes that could be made to the system to slim it down, but maintain its robust nature.
Modify
ViewEvent#getType()- This method should return a macro level type, instead of the micro level that currently is shared. Right now the list is thick, and a user might very well need multiple interactions to resolve a single task. Any situation where there is aisXXXXEvent()method that merges these types into a single boolean should also be a single type inViewEvent#getType().Add
ViewEvent#getTypeSpecific()- Given that there are probably very good reasons to retain these split types, there should be an allowance for types to have subtypes, and there should be a method to get those. This will allow for all current functionality to be maintained, but gives more granularity and control for new, general, and veteran users of the library.Convert
ViewEventto an abstract class with typed descendants instead of including everything in the same class - This is an alternative suggestion to the previous two steps, and arguably a better choice for SnapKit's long-term use. Right now the capabilities of SnapKit's event system are restricted to those included in the library, there is no way for a user to create a new type of ViewEvent and slot it into the system. Converting each of the types into their own class would use the core ability of Java to maintain these type systems, without relying on Enums and hardset classes that a future user cannot extend.This one is a little more complicated than the last two, and would require a reworking of how the inheritance currently works. How I would do it is have the implementation (Cheerp vs Swing) as an object stored inside of the SnapKit environment itself (or if we must inside the event, but that is less good), and then let the inheritance of ViewEvent be all about the different types of ViewEvents. This then lets subtypes just be extensions of the children, which is more aligned with Java's general behaviour with such things. I believe it is also a more intuitive system for newcomers, as it also makes the system extensible for future purposes.
The above list will be modified as more improvements/changes are found.