I would say less overuse of final, more underuse of interfaces. If everything takes/returns/stores values by interfaces (excluding data containers with no behavior) then you don't need to "jailbreak" any class to mock it.
Of course you get code bloat defining interfaces for everything you intend to implement once, and you have to enforce these rules, but this is something that could be made easier. Not in Java, but imagine a language where:
- Concrete classes can only be used in new, or in some platform provided DI container.
- Methods can only accept interface types and return interface types.
- Fields are private only, all public/protected is via properties (or getters/setters, it just has to be declarable in an interface)
- You have a ".interface" syntax (akin to ".class" but for types) that refers to the public members of a class without tying you to the concrete class itself. You can use this as a shorthand instead of declaring separate interfaces for everything.
Eg.
```
final class GDrive { ... }
public Download file(GDrive.interface drive) { ... }
class MockDrive implements GDrive.interface { ... }
```
The closest I can think of is a hypothetical typed variant of NewSpeak, but maybe something like this exists already?
> I would say less overuse of final, more underuse of interfaces.
Interfaces with one implementation are terrible. They just clutter everything and make the code navigation a pain, so it's good that people are avoiding them.
Perhaps a special "test-only" mode that allows to patch finals is a better idea.
Custom classloaders and Java agents allow to modify bytecode before it loads into JVM, so it's possible to remove `final`, modify visibility scope and perform basically anything.
I always wonder what is the motivation when people do interfaces with
just one implementation.
I mean, using this logic, every single function can be hidden behind an
interface. Even the sole implementation of the interface can be hidden
behind a yet another interface.
If there's just one implementation, then the interface is not necessary!
An interface, esp. when returned from a method, is the best way the define a limited contract. If you return the concrete class, you have the following potential issues:
- Very broad, unspecific contract that may even obscure the methods purpose
- You cannot modify the contract without modifying the class AND vice versa
- Shrinking a contract (taking away elements) is far harder and more likely to cause breakages in other code than growing a contract
- Mocks become more cumbersome because the contract is so broad
- Changes to the concrete class cause ripple effects in code that doesn't care about the change
I think you've navigated away from the scope of my remark; I've
specifically asked what's the point of using interfaces when there's
just one implementation, not "what is the point of interfaces" in
general.
One motivation is to separate interface and implementation. Using interface allows one to easily observe available methods in a one place. With class, one must use IDEs to filter out hundreds irrelevant lines just to find out class contract. If you ever used Delphi or C++, it provides much better experience by clearly separating class interface and class implementation.
I seed a torrent of the SICP lectures that originally came from IA, I'll have to see if that's still up and if there's some way of getting the other torrents from the tracker.
If you're lucky there's other seeds around, and not just the IA web seeds which (I assume?) are down too.
> and the nucleus of an atom or neutron star has a density on the order of 4x10^17...if you can build the entire ship out of pure neutrons, you're still coming up short by a factor of ~100
Would you be getting into black hole territiry at that density?
Have MS managed to figure out window snapping for WSLg yet? From what I've heard (maybe this is dated) there are a bunch of limitations that come from them using a primitive compositor for their Wayland setup.
Xpra (or even a full X server, if you don't mind losing X clients on sleep) has been a lot better on the integration front.
> GIMP will stall for 10-15 seconds at startup looking for XSANE plugins. Apparently it's calling some external server, bad in itself, and that external server is slow. Worse, this delay stalls out the entire GUI for both GIMP and other programs.
Do you remember where you came across that explanation?
I'd be very surprised if it weren't something like an mDNS query with a high timeout. Which is it's own problem (ideally it'd be async), but a far cry from it trying to access something on the internet.
Huh, my other pages don't have the same issue. I guess the search indexer must've died - I'll restart it in an hour or two.
FWIW, the snapshot of c2 that this runs off of is somewhat dated (https://archive.org/details/c2.com-wiki_201501), so the last ~7 years of updates after the move to the federated wiki aren't present.
Does anyone know where these original pages ended up in fedwiki after the migration?
You might find Chess960 interesting then. The starting position is randomized, with enough variations that memorizing an opening book no longer really helps. You have to start evaluating the board from move 1 in the same way that you do 20 moves later.
> I think I’ve had more trouble with data loss from Evernote than those index cards, ironically…
Plain text file and a text editor app, assuming rich content isn't a requirement. There are a million of them - personally, I've never had OldSchool Editor eat my data.
I looked into the equivalent setup for WSL a while ago. The thing I could never solve was: how to manage the hosts windows via the virtual environment's WM? Without the integration that setup is just extra config for no gain.
Because if most tools belong to the VM, then just run a VM in full screen and use that. No need to have the display server shared if you're using mostly Linux tools that display on the VM's X server.
That’s a good point. I’ll try out the VM route and see how that goes. I mainly just want to tile the web browser, some docs, a terminal emulator and vim/IDE and be able to switch between layouts and apps seamlessly and VM does seem like a good option. Kinda sad that macOS WM is a joke to do all this compared to some of the TWMs out there.
Of course you get code bloat defining interfaces for everything you intend to implement once, and you have to enforce these rules, but this is something that could be made easier. Not in Java, but imagine a language where:
- Concrete classes can only be used in new, or in some platform provided DI container.
- Methods can only accept interface types and return interface types.
- Fields are private only, all public/protected is via properties (or getters/setters, it just has to be declarable in an interface)
- You have a ".interface" syntax (akin to ".class" but for types) that refers to the public members of a class without tying you to the concrete class itself. You can use this as a shorthand instead of declaring separate interfaces for everything.
Eg.
```
final class GDrive { ... }
public Download file(GDrive.interface drive) { ... }
class MockDrive implements GDrive.interface { ... }
```
The closest I can think of is a hypothetical typed variant of NewSpeak, but maybe something like this exists already?