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
@FunctionalInterface
public interface Cleanup extends DokanCallback {
void callback(WString rawPath, DokanFileInfo dokanFileInfo);
public static final Cleanup DEFAULT = (rawPath, dokanFileInfo) -> {}; //default NO-OP
}
(For ZwCreateFile, for example, you can provide the very reasonable default NIO code, that is already there!)
Then in DokanyOperations you can initialize the class with reasonable defaults (note how I renamed the class field name, more on that later)
public class DokanyOperations extends Structure{
...
public Cleanup cleanup = Cleanup.DEFAULT;
}
and objects of class DonanyOperations are usable immediately after creation:
DokanyOperations do = new DokanyOperations();//Usable, no null pointer exceptions!
The bigger advantage, however, is that developers can easily create their own DokanyOperation classes overriding defaults only for what they need to:
class MySpecificDoknayOperations extends DonanyOperations{
MySpecificDoknayOperations(){
//I only override the operations I care about in this constructor!
this.cleaner = MyDonayOperations::myOwnCleanup;
}
//I may want to keep this private .. or not!
private void myOwnCleanup (WString rawPath, DokanFileInfo dokanFileInfo){
...
}
}
NOTE 1
The above enhancement represents an alternative, simpler, more functional approach to extending dokan-java compared to the big interfaces/classes DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub.
However, you can still keep DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub around.
NOTE 2
Also there is no need for questionable use of reflection/annotations and the associated risks with this (for example: what if I make spelling error and annotate with NotImplemented("ZWCreateFile")? Will I get a silent failure at runtime?)
NOTE 3
Not sure why DokanOperations breaks the Java conventions for naming member fields? Is this a JNA thing? For example it should be this: public ZwCreateFile zwCreateFile = null;
and not this: public ZwCreateFile ZwCreateFile = null;
Naming the member exactly as the interface is bad a idea - can we change the name either of the field or the interface? This will make the above patch a bit more convoluted, because: private Cleanup Cleanup = Cleanup.DEFAULT;
is illegal in Java.
NOTE 4
Please consider getting all DokanCallback interfaces out of the DokanOperations class. It may be easier for developers to find them (although keeping them inside the class is probably fine, never confused me)
The text was updated successfully, but these errors were encountered:
hrstoyanov
changed the title
Add a default, NO-OP implementation to every DokanCallback functional interface.
Add a default, default (or no-op) implementation to every DokanCallback functional interface.
Jul 26, 2020
hrstoyanov
changed the title
Add a default, default (or no-op) implementation to every DokanCallback functional interface.
Add a default (or no-op) implementation to every DokanCallback functional interface.
Jul 26, 2020
hrstoyanov
changed the title
Add a default (or no-op) implementation to every DokanCallback functional interface.
Add a default (no-op?) implementation to every DokanCallback functional interface.
Jul 26, 2020
For example:
(For ZwCreateFile, for example, you can provide the very reasonable default NIO code, that is already there!)
Then in DokanyOperations you can initialize the class with reasonable defaults (note how I renamed the class field name, more on that later)
and objects of class DonanyOperations are usable immediately after creation:
The bigger advantage, however, is that developers can easily create their own DokanyOperation classes overriding defaults only for what they need to:
NOTE 1
The above enhancement represents an alternative, simpler, more functional approach to extending dokan-java compared to the big interfaces/classes DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub.
However, you can still keep DokanFileSystem/AbsrarctDokanFileSystem/DokanFileSystemStub around.
NOTE 2
Also there is no need for questionable use of reflection/annotations and the associated risks with this (for example: what if I make spelling error and annotate with NotImplemented("ZWCreateFile")? Will I get a silent failure at runtime?)
NOTE 3
Not sure why DokanOperations breaks the Java conventions for naming member fields? Is this a JNA thing? For example it should be this:
public ZwCreateFile zwCreateFile = null;
and not this:
public ZwCreateFile ZwCreateFile = null;
Naming the member exactly as the interface is bad a idea - can we change the name either of the field or the interface? This will make the above patch a bit more convoluted, because:
private Cleanup Cleanup = Cleanup.DEFAULT;
is illegal in Java.
NOTE 4
Please consider getting all DokanCallback interfaces out of the DokanOperations class. It may be easier for developers to find them (although keeping them inside the class is probably fine, never confused me)
The text was updated successfully, but these errors were encountered: