add unified interface for accessing file system

**please review**
But Cosmin, creating the monolithic dependency is the entire purpose of
this code review. I need this because the direction I want to take the
performance of the application in requires that no code except FileUtil
have any knowledge of the current working directory. And all four of the
paths in this class ultimately are relative to the current directory. And
if we don't establish a clear paradigm for accessing files, it becomes too
likely that bugs will slip through as a result of this and lead to
situations that are very difficult to correct and fix. Sometimes having a
very clear API /is/ desirable for exactly the reason you are so disdainful
of. To make it easy to avoid easy-to-make mistakes.

Okay, I'm gonna merge this. I'm sorry you feel so frustrated that people
aren't listening to you. Believe it or not, though, we are. I am just
considering other factors in addition to the ones that you have yourself
mentioned.

On Tue, Oct 21, 2014 at 10:26 AM, Cosmin Radoi <notifications@github.com>
wrote:

> In
> java-backend/src/main/java/org/kframework/backend/java/symbolic/JavaSymbolicBackend.java:
>
> > @@ -69,8 +71,7 @@ public Definition lastStep(Definition javaDef) {
> >
> >          definition.setIndex(index.get());
> >
> > -        loader.saveOrDie(new File(context.kompiled,
> > -                JavaSymbolicBackend.DEFINITION_FILENAME).toString(),
> > +        loader.saveOrDie(files.resolveKompiled(JavaSymbolicBackend.DEFINITION_FILENAME),
>
>  Cosmin, the problem with this approach is I'd like to reach a point
> where FileUtil or classes like it are the only objects constructing File
> instances.
>
> Why would you even want this?
>
> I definitely can do what you describe, but it provides a less nice API to
> the user who wants to read and write to files.
>
> So new File(kompiledDir, foo) is uglier then files.resolveKompiled(foo)?
> If you don't like it, you could even provide some helper methods/classes.
> But don't make them into a monolithic dependency that needs to be passed
> around everywhere.
>
> We end up back in the situation we started with where very little is
> stopping the user from unknowingly breaking the paradigm by constructing
> their paths manually.
>
> kompiledDir/mystuff is not rocket science. What I'm reading here is that
> if we entangle this enough, and make it hard enough for the developer, he
> won't make mistakes anymore. It might be true, because he won't develop
> anything new -- he will spend his time writing mocking code for all the
> dependencies.
>
> Another way to put this, if you want a more engineerish explanation, is
> that your approach increases the coupling of the system. And with very
> little gain.
>
> I know you hate Guice
>
> You know wrong. I don't hate Guice. I see Guice as a nice thick rug. It
> can be comfortable, and thus useful. But, being thick, you can also shove a
> lot of dirt under it. The dirt is the high coupling.
>
> I'm going to give you a chance to respond again to this to note your
> objections, but then I'm going to merge this. It's good to express your
> opinions, but it's also good to accept that sometimes the project decides
> to go in a different direction than you see as ideal yourself.
>
> Thank you for the opportunity to object without effect! I've been doing
> this quite a bit lately.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/kframework/k/pull/1070/files#r19155388>.
>