2.8.0 Upgrades

[Josh Suereth]

All,

I've started a wiki article to work through upgrading the scalax.io interfaces for 2.8.0 features.   Please let me know your thoughts!

http://wiki.github.com/eengbrec/Scalax.IO/upgraded-io-design-for-280-features

- Josh

[Erik Engbrecht]

I think the trait File should be split apart so that files and directories have separate traits as follows because there are operations you can perform on files that you can't perform on directories and vice-versa.

trait Path {

  // methods common to both Files and Directories

}

trait Directory extends Path {

  // directory specific methods

}

trait File extends Path {

  // file specific methods

}

I'll post some updates later on tonight.

On Sun, Jun 21, 2009 at 8:21 PM, Josh Suereth <joshua.suereth@...> wrote:

All,

I've started a wiki article to work through upgrading the scalax.io interfaces for 2.8.0 features.   Please let me know your thoughts!

http://wiki.github.com/eengbrec/Scalax.IO/upgraded-io-design-for-280-features

- Josh

--
http://erikengbrecht.blogspot.com/

[Stepan Koltsov]

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:

> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

[Rafael de F. Ferreira-3]

--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/



On Sat, Jun 27, 2009 at 7:39 PM, Stepan Koltsov<yozh@...> wrote:

> On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
>> I think the trait File should be split apart so that files and directories
>> have separate traits as follows because there are operations you can perform
>> on files that you can't perform on directories and vice-versa.
>> trait Path {
>>   // methods common to both Files and Directories
>> }
>> trait Directory extends Path {
>>   // directory specific methods
>> }
>> trait File extends Path {
>>   // file specific methods
>> }
>> I'll post some updates later on tonight.
>
> It is wrong, because of two reasons: performance and useability.
>
> Perfornane: When you listing directory, you only get file names. To
> get file type you have to call isDirectory for each file in that
> directory. It could be slow.
>
> Useability. Some people prefer calling isDirectory than doing pattern matching.
>
> S.
>
>

[Erik Engbrecht]

re: performance

The "wrongness" of such a solution depends on what your objectives are.  In many cases the added type-safety would outweigh the performance impact.  Assuming there is a performance impact.  I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted.  I can think of a couple different ways to do it.

re: isDirectory vs pattern matching

People have their preferences.  I don't see why both can't be supported.

re: underlying issue

What's more important:  Performance or type safety?  Low-level access or "doing the right thing?"  I lean toward type safety and doing the right thing because people can always drop down the Java APIs.  I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

[Josh Suereth]

I see the path trait becoming java's file class.  Pattern matching against files and directries could be handy.

I'm in the fence with this one.  However I think a well designed path trait (Composite pattern) + pattern matching could win out here.

Besides performance (against the spoon to be obsolete java file API). Are there anyother reasons?)

Sent from my iPhone

On Jun 27, 2009, at 8:09 PM, Erik Engbrecht <erik.engbrecht@...> wrote:

re: performance

The "wrongness" of such a solution depends on what your objectives are.  In many cases the added type-safety would outweigh the performance impact.  Assuming there is a performance impact.  I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted.  I can think of a couple different ways to do it.

re: isDirectory vs pattern matching

People have their preferences.  I don't see why both can't be supported.

re: underlying issue

What's more important:  Performance or type safety?  Low-level access or "doing the right thing?"  I lean toward type safety and doing the right thing because people can always drop down the Java APIs.  I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

[Erik Engbrecht]

What I have (locally) right now is looking like:

trait Location {

  // stuff common to files and directories

}

trait File extends Location {

  // stuff specific to files

  // kind of like JSR203 FileRef only with the stuff from JSR203 Path that applies to Files

  // http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileRef.html

}

trait Directory extends Location {

  // stuff specific to directories

}

trait Path extends Location {

  // stuff roughly equivalent to a JSR203 path, objects that can be a File or a Directory

  // http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html

}

Then there's the java.io.File wrappers which form a parallel hierarchy, along with mixins so implementation isn't duplicated between File/Directory and Path.

On Sun, Jun 28, 2009 at 9:46 AM, Josh Suereth <joshua.suereth@...> wrote:

I see the path trait becoming java's file class.  Pattern matching against files and directries could be handy.

I'm in the fence with this one.  However I think a well designed path trait (Composite pattern) + pattern matching could win out here.

Besides performance (against the spoon to be obsolete java file API). Are there anyother reasons?)

Sent from my iPhone

On Jun 27, 2009, at 8:09 PM, Erik Engbrecht <erik.engbrecht@...> wrote:

re: performance

The "wrongness" of such a solution depends on what your objectives are.  In many cases the added type-safety would outweigh the performance impact.  Assuming there is a performance impact.  I don't see why the API couldn't be designed to avoid the isDirectory calls where they aren't wanted.  I can think of a couple different ways to do it.

re: isDirectory vs pattern matching

People have their preferences.  I don't see why both can't be supported.

re: underlying issue

What's more important:  Performance or type safety?  Low-level access or "doing the right thing?"  I lean toward type safety and doing the right thing because people can always drop down the Java APIs.  I don't see a lot of value in creating wrapper classes that just mimic the objects they wrap.

On Sat, Jun 27, 2009 at 6:39 PM, Stepan Koltsov <yozh@...yozh@...> wrote:

On Sun, Jun 28, 2009 at 00:28, Erik Engbrecht<erik.engbrecht@...erik.engbrecht@...> wrote:
> I think the trait File should be split apart so that files and directories
> have separate traits as follows because there are operations you can perform
> on files that you can't perform on directories and vice-versa.
> trait Path {
>   // methods common to both Files and Directories
> }
> trait Directory extends Path {
>   // directory specific methods
> }
> trait File extends Path {
>   // file specific methods
> }
> I'll post some updates later on tonight.

It is wrong, because of two reasons: performance and useability.

Perfornane: When you listing directory, you only get file names. To
get file type you have to call isDirectory for each file in that
directory. It could be slow.

Useability. Some people prefer calling isDirectory than doing pattern matching.

S.

--
http://erikengbrecht.blogspot.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The Scala BEAST" group.
To post to this group, send email to scala-beast@...
To unsubscribe from this group, send email to scala-beast%2Bunsubscribe@...
For more options, visit this group at http://groups.google.com/group/scala-beast?hl=en
-~----------~----~----~----~------~----~------~--~---

--
http://erikengbrecht.blogspot.com/