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

Allow traversal to home directory with single button click - p4 #12

Closed
DaveJarvis opened this issue Apr 8, 2021 · 3 comments
Closed
Assignees

Comments

@DaveJarvis
Copy link
Collaborator

DaveJarvis commented Apr 8, 2021

When opening a file, it's convenient to have a single button that may be clicked to navigate to the user's home directory. For example:

  1. File chooser opens
  2. Click "Home" icon
    • File chooser navigates to System.getProperty( "user.home" ); value

Optionally, a button to navigate to the "user.dir" directory (user working directory) may be useful.

@DaveJarvis DaveJarvis changed the title Home button Allow traversal to home directory with single button click Apr 8, 2021
@DaveJarvis DaveJarvis changed the title Allow traversal to home directory with single button click Allow traversal to home directory with single button click - p4 Apr 9, 2021
@io7m
Copy link
Owner

io7m commented Apr 9, 2021

Yep, sounds good. I'd like to pass both of those values in via the immutable configuration value (as Optional<Path> values), and then only show the buttons if those values have been provided.

@DaveJarvis
Copy link
Collaborator Author

DaveJarvis commented Apr 9, 2021

For what it's worth, see https://rules.sonarsource.com/java/RSPEC-3553 :

The Java language authors have been quite frank that Optional was intended for use only as a return type, as a way to convey that a method may or may not return a value.

@io7m
Copy link
Owner

io7m commented Apr 10, 2021

And for that, it's valuable but using Optional on the input side increases the work you have to do in the
method without really increasing the value. With an Optional parameter, you go from having 2 possible inputs:
null and not-null, to three: null, non-null-without-value, and non-null-with-value. Add to that the fact that
overloading has long been available to convey that some parameters are optional, and there's really no reason
to have Optional parameters.

I completely disagree with their assessment, and their complaints actually don't apply in this particular case.

With an Optional parameter, you go from having 2 possible inputs...

Nope. Sensible codebases reject null as a value anywhere. It was a language design mistake to have pervasive nullable references everywhere, and it's a mistake that hasn't been repeated in modern languages that have more sensible type systems. null is never an acceptable value in the jwheatsheaf codebase.

Additionally, immutables.org generated types include the following methods for a property x of type Optional<T>:

Builder setX(T x);
Builder setX(Optional<T> x);

So the "it's inconvenient to wrap values in Optional" criticism doesn't apply. Both methods reject null values immediately.

A key point that everyone misses is that in null-hostile codebases, Optional is the one and only technique by which we indicate that a value may not be present at the type level. A nullable reference T communicates absolutely nothing; it might be safe to dereference, it might not - at least with Optional<T>, the mere presence of the Optional type indicates to you that you should be checking first.

When Project Valhalla is completed, we'll have a way to express truly non-null values at the type level. As the next stages of Project Amber are completed, we'll gain the ability to pattern match on Optional values and I suspect some of the unsafe methods on Optional (such as get) will be deprecated...

if (x instanceof Optional.of(y)) {
  // safely use the guaranteed-non-null y value here
}

@io7m io7m self-assigned this Apr 11, 2021
@io7m io7m closed this as completed in af9be6b Apr 11, 2021
io7m added a commit that referenced this issue Apr 11, 2021
This adds an API for constructing rule-based glob filters for files.

Fix: #12
io7m added a commit that referenced this issue May 18, 2021
Release: com.io7m.jwheatsheaf 3.0.0

A big thanks to @DaveJarvis for suggestions, bug reports, and some
code contributions!

Change: Add the ability to specify custom strings (Ticket: #7)
Change: Add the ability to confirm file selections (Ticket: #17)
Change: Allow for including ".." in directory listings (Ticket: #23)
Change: Improve "select directly" dialog behaviour (Ticket: #29)
Change: Fix the size formatter (Ticket: #30)
Change: Use the default filesystem by default (Ticket: #21)
Change: Add support for glob-based filters (Ticket: #19)
Change: Improve filename field behaviour (Ticket: #28)
Change: Add an optional home directory button (Ticket: #12)
Change: Enable sorting of directory items (Ticket: #22)
Change: Allow for setting a default file filter (Ticket: #9)
Change: Allow the escape key to close file choosers (Ticket: #14)
Change: Allow for specifying an initial filename in choosers (Ticket: #15)
Change: Allow for specifying custom dialog titles (Ticket: #8)
Change: Make the default filters part of the public API (Ticket: #10)
io7m added a commit that referenced this issue May 18, 2021
Release: com.io7m.jwheatsheaf 3.0.0

A big thanks to @DaveJarvis for suggestions, bug reports, and some
code contributions!

Change: Add the ability to specify custom strings (Ticket: #7)
Change: Add the ability to confirm file selections (Ticket: #17)
Change: Allow for including ".." in directory listings (Ticket: #23)
Change: Improve "select directly" dialog behaviour (Ticket: #29)
Change: Fix the size formatter (Ticket: #30)
Change: Use the default filesystem by default (Ticket: #21)
Change: Add support for glob-based filters (Ticket: #19)
Change: Improve filename field behaviour (Ticket: #28)
Change: Add an optional home directory button (Ticket: #12)
Change: Enable sorting of directory items (Ticket: #22)
Change: Allow for setting a default file filter (Ticket: #9)
Change: Allow the escape key to close file choosers (Ticket: #14)
Change: Allow for specifying an initial filename in choosers (Ticket: #15)
Change: Allow for specifying custom dialog titles (Ticket: #8)
Change: Make the default filters part of the public API (Ticket: #10)
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

2 participants