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

Add a default (no-op?) implementation to every DokanCallback functional interface. #53

Open
hrstoyanov opened this issue Jul 26, 2020 · 1 comment

Comments

@hrstoyanov
Copy link

hrstoyanov commented Jul 26, 2020

For example:

@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)

@hrstoyanov 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 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 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
@hrstoyanov hrstoyanov reopened this Jul 27, 2020
@hrstoyanov
Copy link
Author

closing this, since I found a way to get what I want whitout asking you to do changes.

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

1 participant