That's where other abstractions are needed, rather than abstractions leaking.
There isn't really a way to choose immutability to the bitter end, as our PCs don't work that way. At some level you go ugly, it's just that we tend to go ugly early. At one end of the spectrum, you have Haskell, where even functions that require file I/O are kept pure. E.g., hFileSize takes a Handle and returns an IO Integer, which is somewhat like a Future<Integer> in Java. At the more popular end of the spectrum, it's rare to keep even the implementation of mathematical functions pure, not least because doing so relies on the pretty poor implementations of recursion in most languages. But even in Haskell, the compiler will generate code that goes ugly. It needs to be able to overwrite existing values when it knows that's safe, because otherwise every Haskell program would be a massive memory leak and slow too. Personally I'd rather leave the ugly code to the guys writing the compiler. On Sun, Mar 13, 2011 at 2:09 PM, Alexey Zinger <[email protected]>wrote: > File systems -- and I/O in general -- tend to throw a big monkey wrench > into the whole immutability conversation. In some ways, this is where > theory and reality of computing collide and some abstractions start to > leak. I suggest sometimes it's rather pointless to choice immutability to > the bitter end if there is no real tangible benefit. While we can agree > that there are many design flaws in java.io in general, I think there's > only so much designing that can be done around the fact that we need to be > able to pass around references to entities that describe some persistence or > I/O artifacts, and at the same time, by their nature, they exist with the > purpose of having side-effects. > > In situations like this, I usually don't agonize over File and streams and > so on, but design some architecture around the bigger concepts of > persistence itself and allow my framework to expose its state in thread-safe > manner as needed. This lets me pass around some abstractions that have very > well defined side-effects in a way that makes them "functional-friendly", > while under the hood my persistence framework might look a lot more > procedural with fairly traditional flow of control and synchronization > patterns. > > Alexey > 2001 Honda CBR600F4i (CCS) > 1998 Honda RS125 (CCS) > 2002 Suzuki Bandit 1200S > http://azinger.blogspot.com > http://bsheet.sourceforge.net > http://wcollage.sourceforge.net > > > ------------------------------ > *From:* Fabrizio Giudici <[email protected]> > *To:* The Java Posse <[email protected]> > *Sent:* Sun, March 13, 2011 11:44:28 AM > *Subject:* [The Java Posse] Some design questions (about immutability and > other stuff) > > A parallel discussion at the Lombok mailing list revamped some thoughts and > doubts about immutability. I'd like have some feedback about it. > > Given that immutability is a "turtles all the way down" thing ("turtleness" > in the following), a poster raised doubts about things such as File. File is > immutable for what concerns its internal state (the path), but all methods > that actually work on the related file don't always return the same values > (or do the same thing) because they refer to the actual file which is > mutable. > > Such a class is regarded as mutable or immutable? Of course, I'm interested > in the practical purposes. > > Curiously, the "anemic object" antipattern is something that would help > here. If you defined File only as a wrapper on a path, and FileSystem > another class which accepts a File as argument, you would have clearly > separated the mutable and immutable portions. > > But I don't like anemic objects. When I can, I just separate the two parts > in two different objects, but they stay bound together. Referring to some > actual code that I'm not using in production but for some tutorial, I have > a: > > FileModel fileModel = new FileModel("/foo/bar"); > String path = fileModel.getPath(); > String name = fileModel.getName(); > > and the above two methods are the only two specific methods of FileModel. > So far, it's anemic and immutable. Going on: > > fileModel.as(Removable).remove(); > long size = fileModel.as(SizedInBytes).getSize(); > List<FileModel> children = > fileModel.as(Composite).findChildren().results(); > > > That as() is my way to deal with DCI and Semantic models. In simple words, > it just recovers a "role" of FileModel by referring to its interface - > as(Removable) is a shortcut for as(Removable.class). All the roles in the > example above are simple, stateless objects that work on the real > filesystem. Clearly, I've separated behaviours: FileModel on its own > encapsulates the really immutable portion, while roles keep the remainder > behaviours. But there's no turtleness in FileModel, because there's only a > single level of turtles (i.e., fileModel.as() always returns the same thing > for each role, but the returned object is not immutable in the strict > definition). > > There are variations on the theme. Some roles are de facto hardwired in > FileModel; others can be dinamically injected by the context. But once a > role has been injected into a FileModel instance, it stays forever. > > How do you comment about immutableness of FileModel? As said, there's no > turtleness. It's enough to say that FileModel is not immutable? > > > PS Another related question is about equals() and hashCode()... Are two > FileModel instances with the same path, but possibly different roles, > equals()? I'd say not. But this is another question, and more related of the > broken definition of equality in Java. > > -- Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici - www.tidalwave.it/people > [email protected] > > -- 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 javaposse+ > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > -- > 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. > -- 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.
