are directories files?

[Tum]

Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use
names like "IFileName" which sounds nice compared to "INodeName" and fits
with the "FileSystem" moniker. A has the disadvantage that IDirectory has a
GetContent() method which isn't bad but can be considered a bit weird. It
probably wouldn't be too hard to make users think of everything as a file.

Method B is nice cause IDirectory doesn't have GetContent() -- that honour
belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName
and it's a bit weird to have everything based on something called a "Node"
when the system is called a "File System" but this method feels more "pure"
in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure unless
you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

[Ryan Stewart]

"Tum" <sp**@spam.com> wrote in message
news:%8********************@news02.tsnz.net...

Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use
names like "IFileName" which sounds nice compared to "INodeName" and fits
with the "FileSystem" moniker. A has the disadvantage that IDirectory has a GetContent() method which isn't bad but can be considered a bit weird. It
probably wouldn't be too hard to make users think of everything as a file.

Method B is nice cause IDirectory doesn't have GetContent() -- that honour
belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName
and it's a bit weird to have everything based on something called a "Node"
when the system is called a "File System" but this method feels more "pure" in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure unless you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

Since java.io.File covers both files and directories, it's not exactly a new
way of thinking.

[nos]

"Ryan Stewart" <zz********@gSPAMo.com> wrote in message
news:p8********************@texas.net...

"Tum" <sp**@spam.com> wrote in message
news:%8********************@news02.tsnz.net...

Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use names like "IFileName" which sounds nice compared to "INodeName" and fits with the "FileSystem" moniker. A has the disadvantage that IDirectory has

a

GetContent() method which isn't bad but can be considered a bit weird.

It probably wouldn't be too hard to make users think of everything as a file.
Method B is nice cause IDirectory doesn't have GetContent() -- that honour belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName and it's a bit weird to have everything based on something called a "Node" when the system is called a "File System" but this method feels more

"pure"

in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure

unless

you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

Since java.io.File covers both files and directories, it's not exactly a

new way of thinking.

This works

File f = new File(".");

[S Manohar]

> > > Do you reckon I can get away with Method A? It doesn't seem as pure

unless

you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...

Since java.io.File covers both files and directories, it's not exactly a

new

way of thinking.

This works

File f = new File(".");

Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?

[nos]

"S Manohar" <sg*******@hotmail.com> wrote in message news:2e**************************@posting.google.c om...

> Do you reckon I can get away with Method A? It doesn't seem as pure

unless

> you spend a long time convincing yourself that (for all intents and
> purposes) a file *is* a node (it's just got a different name) and a
> directory *is* a file.
>
> A penny for anyone's thoughts...
>
Since java.io.File covers both files and directories, it's not exactly a

new

way of thinking.

This works

File f = new File(".");

Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?

rewrite routines twice???

[FISH]

sg*******@hotmail.com (S Manohar) wrote in message news:<2e**************************@posting.google. com>...
[snipped...]

Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?

It would appear that the only difference between files and directories
is their content type. A file has binary content, and the content
length is the number of bytes. A directory has list content, and the
content length is the number of entries in the list. Aside from this
there is practically no difference. Both have names, attributes and
permissions. Both can be 'soft' and 'hard' linked. Both can be
created, copied, moved and deleted.

So, you *can* think of them as one type of object with two content
type variations. Whether or not your *do* think of them in this way
is entirely dependent upon what you are doing!
-FISH- ><>