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

Improve EnumInteger-System #41

Merged
merged 23 commits into from
Jun 2, 2020

Conversation

JaniruTEC
Copy link
Member

@JaniruTEC JaniruTEC commented May 24, 2020

Added new package conv (conversion)
Added convenience methods
Added missing static methods
Added IntegerConvertible as base interface of EnumInteger
Added MaskValue as special case of EnumInteger that is used to express masks
Renamed EnumIntegerSet to MaskValueSet and changed it to only accept MaskValues
Made EnumIntegerSet an interface and added EnumIntegerSetImpl as implementation
Renamed enumSetFromInt to getSetFromInt maskValueSet

Moved EnumInteger to new package conv (conversion) as first step to refactoring the EnumInteger-System
Moved the appropiate Test
Updated imports in all accessors
Moved EnumIntegerSet to package conv
Moved the appropiate Test
Updated imports in all accessors
Generified EnumInteger to not necessarily represent a bitmask, but an intValue that represents the Enum
Modified depended classes to reflect this change
Modified Tests to reflect this change

Added overloaded version of EnumInteger#enumFromInt that accepts an enum-type instead of an array of possible values
Renamed EnumIntegerSet to MaskValueSet
Updated depended classes
Renamed appropriate Test
Changed MaskValueSet to only accept MaskValueEnums (and therefore match it's contract)
Changed MaskValueSet to an interface and added class MaskValueSetImpl as implementor
…hod and renamed #fromInt

Renamed MaskValueSet#enumSetFromInt to #getSetFromInt
Renamed #fromInt in MaskValueEnums to #getSetFromInt
Added #getSetFromInt to MaskValueEnums where it was missing
Updated depended classes

Added overloaded version of MaskValueSet#getSetFromInt that accepts an enum-type instead of an array of possible values

Added delegate-method (getSetFromInt) to MaskValueEnum
Added #fromInt to EnumIntegers where it was missing
@JaniruTEC JaniruTEC marked this pull request as draft May 27, 2020 23:28
@JaniruTEC JaniruTEC marked this pull request as ready for review May 28, 2020 12:27
Copy link
Member

@infeo infeo left a comment

Choose a reason for hiding this comment

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

First of all. thank you for this pull request. It adds typesafety and reduces wrong use of the system.

A thing which should be discussed is the naming of some objects. I don't like the new package name. I assume it stands for conversion, but conversion would only contain classes for the conversion action, not the conversion results. I suggest the package name wrapper, because the int value is wrapped in a type safe manner and in the end these objects still represent the value, therefore wrap it.

The comments for MountOption.java hold basically for all classes implementing the MaskValueEnum.

Splitting the MaskValueEnum into interface and implementation is overengineering for this library, but acceptable from my point of view.

@JaniruTEC
Copy link
Member Author

JaniruTEC commented May 28, 2020

A thing which should be discussed is the naming of some objects. I don't like the new package name. I assume it stands for conversion, but conversion would only contain classes for the conversion action, not the conversion results. I suggest the package name wrapper, because the int value is wrapped in a type safe manner and in the end these objects still represent the value, therefore wrap it.

conv does indeed stand for conversion. While I understand your suggestion wrapper wouldn't be a good name either because it's already taken by the #32-API.

The comments for MountOption.java hold basically for all classes implementing the MaskValueEnum.

Same goes for the cases where my comments are missing.

Splitting the MaskValueEnum into interface and implementation is overengineering for this library, but acceptable from my point of view.

For documentation purposes: The idea was to stand in line with the JDK-Collections, where you usually also deal with a lot of interfaces. It also makes swapping out the backend easier in case it's needed.

@infeo
Copy link
Member

infeo commented May 29, 2020

conv does indeed stand for conversion. While I understand your suggestion wrapper wouldn't be a good name either because it's already taken by the #32-API

Because the other PR is currently only in a draft state, we can act independetly of it from my point of view. But even if we consider it, why is it a problem to add both in the same package? The MaskValueSet and others are also convenience classes for easier use. And finally, nowadays package names can be easily changed due to the great IDE support.

@JaniruTEC
Copy link
Member Author

Because the other PR is currently only in a draft state, we can act independetly of it from my point of view. But even if we consider it, why is it a problem to add both in the same package? The MaskValueSet and others are also convenience classes for easier use. And finally, nowadays package names can be easily changed due to the great IDE support.

Putting too many classes into a package can lead to even more confusion than misleading package names. Also the EnumInteger-API is pretty much decoupled from the other wrapper classes and used over the whole project. That's why I wanted to keep it separate.

@JaniruTEC
Copy link
Member Author

Also to have said it:
e042b3d and 3114b10 are the same commit, but 3114b10 has a more detailed message. I somehow messed up with amending the commit. Apologies

@infeo
Copy link
Member

infeo commented May 30, 2020

Because the other PR is currently only in a draft state, we can act independetly of it from my point of view. But even if we consider it, why is it a problem to add both in the same package? The MaskValueSet and others are also convenience classes for easier use. And finally, nowadays package names can be easily changed due to the great IDE support.

the EnumInteger-API is pretty much decoupled from the other wrapper classes and used over the whole project. That's why I wanted to keep it separate.

Good point. How about renaming the package to enumInteger, the name the main interface?

@JaniruTEC JaniruTEC requested a review from infeo May 30, 2020 14:32
@JaniruTEC
Copy link
Member Author

@infeo and I agreed on "masking" as package name.

…lueSet

Added IntegerConvertible as base interface for EnumInteger and MaskValueSet. IntergerConvertible defines the intValue() method and marks classes that can be converted into ints and vice-versa.
Changed EnumInteger to explicitly wrap Enums as special case of IntegerConvertible
Changed MaskValueSet to extend IntegerConvertible and renamed method toInt to intValue in accordance to IntegerConvertible
Changed method calls to refelct this change
@JaniruTEC JaniruTEC added this to the 2.0 milestone May 31, 2020
@JaniruTEC JaniruTEC merged commit 43b8d13 into dokan-dev:develop Jun 2, 2020
@JaniruTEC JaniruTEC deleted the improved-enumintegers branch June 5, 2020 20:11
@JaniruTEC JaniruTEC removed the request for review from infeo June 16, 2020 23:27
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.

2 participants