Mail Archives: cygwin/2001/09/24/19:17:49
Ronald Landheer wrote:
>What's in a name? I have no problem with just keeping the "fhandlers" as
>it's still the file system we're handling - be it virtual, magic or
>otherwise. I see no reason to complicate matters with naming conventions
>for obscure reasons. Anyone who takes a look at the source code and/or
>the docs will know how it works, and whatever I implement will be
>commented in the code, and will probably be accompanied by a file "How
>do magic dirs work?". Other than that, this thread documents the design
>in detail, and if there's a lot of questions about it - which I highly
>doubt, because it's a Cygwin internal matter we're talking about - there
>can always be an FAQ entry. We'd need one if we'd call it dhandlers or
>mhandlers too, if we'd need one at all.
>
>The key to clear programming is not in changing a letter of a name: it's
>in the documentation of both the source code and its functionality.
>Whether you call it fhandlers or dhandlers (or mhandlers) is, IMHO, a
>non-issue.
>
the way fhandler reflect to me is that it handles specific files in the
filesystem. and fhandler classes often have basic file operations (open,
read, write, seek, even ioctl) in mind. the point is, fhandler seems to
me more like a device driver than file system. true, it doesn't matter
whether we debate over names like dhandler or mhandler, even fshandler
is a good name. clarity is not what i stress here, by the way.
however, files and file systems are two different concepts! fhandler
takes care of device files, and fshandler takes care of file system,
visibility, and traversal. of course you could make fhandler take care
of file system's work, but i can tell you, by confusing over the two
different concepts and merge them to one, you'll end up having a really
messy ugly thing. now, talk about programming, i think organization and
architectural design is above all things. of course, organization
implies clarity ... well, if you do want to rant about my obsession with
clarity ... ~_~
maybe i didn't say it in a recognizable fashion last time, but i do hope
to separate *file* handling with *file system* handling.
if cygwin's goal is to implement a unix system on windows, then why
don't we do what unix does? in my opinion, a file object should not need
to worry about its location/path/attribute. all it needs to care is
input and output. in turn, an inode (file system object) should not
worry about input and output. it just takes care of where the file
object is, the file type, and its attribute.
apparently it is not the way it is right now in cygwin. :(
i know that this might sound overly complicated to people. besides, it
sounds more like we're implementing an entire operating system. in some
sense, it is true. whoever decided to have a separate file system in
cygwin then in win32 in the first place should also know where this
ends. you don't do things half-way done. i mean, i'm not forcing anybody
to code the way i want them to. i'll genuinely code this thing if I know
that people like my idea and so it won't end up being hated and discarded.
liulk
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -