On 14 March 2011 15:00, Fabrizio Giudici <[email protected]>wrote:
> On 03/14/2011 03:46 PM, Alexey Zinger wrote:
>
>> I see a small problem with the Scala stuff. Specifically:
>>
>> FileRef
>> - DirectoryFileRef
>> - StreamableFileRef
>> - AppendableFileRef
>> - RandomAccessFileRef
>> - NonExistantFileRef
>>
>> How does this address the scenario of a non-existent file reference
>> "becoming" existent by a side-effect of code elsewhere (maybe outside
>> current execution thread, or the JVM as a whole)?
>>
> In fact, this should be handled with composition rather than inheritance,
> and dynamic composition (I mean, in my example I have a FileModel which is
> pretty "static" and only exposes getPath(), and then you can search in it
> roles such as Removable, Readable, Writable, etc... Roles might be present
> or not in function of the current state of the object. It's another
> interesting discussion, in my perspective is how to implement DCI. While
> Java is easily (and rightfully) blamed for the lack of mixins, that seem to
> help, indeed mixins only allow to work statically. In the end, a dynamic
> solution doesn't require any specific language support, with the exception
> of some sugar. But this is a digression from the original topic.
>
>
Not entirely. I wanted to avoid this approach as potentially confusing, but
another possibility is mixins.
In this case, you'd have FileRef and just the one subclass:
class FileRef
class NonExistantFileRef extends FileRef
trait Directory { self: FileRef => ... }
trait Streamable { self: FileRef => ... }
trait Appendable { self: FileRef => ... }
trait RandomAccessible { self: FileRef => ... }
The return type from attempting to retrieve such a file ref would then be
something like "FileRef with Directory", incorporating all methods from
FileRef, in addition to any methods available to directories.
> But in general, this just feels like a losing battle to me -- trying to
>> apply immutability principles to I/O. Why?
>>
>
> Because since it's a known immutability problem, it's a good testcase to
> discuss how immutability faces with the real world. The idea is not to find
> a "solution", which probably doesnt' exist, but the best trade off.
>
>
> --
> 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]
>
>
--
Kevin Wright
gtalk / msn : [email protected]
<[email protected]>mail: [email protected]
vibe / skype: kev.lee.wright
quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda
"My point today is that, if we wish to count lines of code, we should not
regard them as "lines produced" but as "lines spent": the current
conventional wisdom is so foolish as to book that count on the wrong side of
the ledger" ~ Dijkstra
--
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.
