On 12 October 2010 14:55, Alexey <[email protected]> wrote:

> On Oct 11, 7:22 pm, Kevin Wright <[email protected]> wrote:
> > If there were two distinct classes for these two distinct ideas: FileRef
> and
> > Filesystem, then the problem would go away.
> > Methods like File.isDirectory() would become
> Filesystem.isDirectory(FileRef)
> >  and methods like getCanonicalFile would simply be a mapping from one
> > (immutable) FileRef to another.
>
> This would not change anything.  The difficulty is not with the API in
> this case, though it could probably be better.  The difficulty is with
> the fact that IO does not play nice with the functional concepts.  IO
> is all about side-effects.  Whether you use File or have FileRef and
> Filesystem is immaterial -- someone somewhere will have to take a file
> handle and so something with it.  That's the whole point.  We just
> have to deal with it.  But it's not the end of the world.  There's
> nothing stopping us from writing a nice high-level file/IO management
> library or framework.  In some sense that's what RDBMS is for, but if
> we want something a little lighter, there are surely ways to go about
> that on top of standard file API.


True :)

Taken to it's logical extreme, you make the whole library immutable, and
expose all state-changing operations via an IO Monad - It works quite well
in Haskell.

The interim solution (as I previously suggested) is to isolate those parts
of File that truly do represent an immutable object, and just accept that
the remaining operations aren't referentially transparent, and can have side
effects.


Referential Transparency:
http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
In brief, it describes a pure function: one that will ALWAYS give the same
output for the same input, and won't change any other parts of the system.

-- 
Kevin Wright

mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda

-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.

Reply via email to