Re: 2.8.0 Upgrades

by Erik Engbrecht :: Rate this Message:

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/

« Return to Thread: 2.8.0 Upgrades