Matthew Wilson wrote:
>>>Why can't modules be the directory, rather than the file? Sob, sob.
>>
>>After reading this, I was a bit perplexed and looked at the
>>documentation to check wether it is really true (I haven't done anything
>>bigger than a small test program in D yet, so I haven't messed with
>>modules at all). Unfortunately it seems to be that way :(.

Hmmm. I reread the docs and it seems that there is no explicit mention that there can only be one file per module. One module per file, sure, but not the other way round.

I will try to mess around with this once I get home, but I don't have much hope that it will turn out to be possible to have multiple files in the same module. After all, how would D decide which files to read to import a module? That would only be possible if we had module-directories (*hint* *hint* ;)).

Thinking about it, why not support both module files and module directories? That way small modules could simply reside in a single file without having to create a directory while big ones could use as many files as they want.

The D compiler could perform the following steps:

1. Is there a file with the module name? If so, import it and stop.

2. If there is no file, is there a directory with the module name? If so, import all .d files in that directory. Check wether any module statements inside the files refer to the wrong module. If they do it should be an error. Stop if all files are imported successfully.

3. If there is neither a file nor a directory with the module name then we have an error.


Hauke

Helmut Leitner wrote:
> The registry is very much like a file system, so the interface to it
> might profit from similarities.
> 
> Typically you put information about your software into a part of the
> registry. Set your "current working directory" and work relative to
> this.
> 
> I would like to write:
> 
>    import windows.registry;
>    ...    Registry.SetDirectoryCurrent("\\HKEY_CURRENT_USER\\Software\\Synsoft\\App");

I see one problem with that: the current directory would be global. That is one thing I have always hated about the filesystem as well. If you write a library you need to make sure not to modify the current directory because the application might need it to be unchanged. If you write an application you have to account for the fact that a library might change the current directory, because not all library authors stick to the same rules.

So I usually end up not using the current directory at all. Instead I store the reference path somewhere and manually convert all relative paths to absolute paths before I call a filesystem function.

The problem could be solved if there was a Registry object so that the current directory could be local to those parts of the software that use the same object.

Hauke

On Fri, 19 Sep 2003 17:21:49 +0200, Hauke Duden <H.NS.Duden@gmx.net> wrote:
>The D compiler could perform the following steps:
>
>1. Is there a file with the module name? If so, import it and stop.
>
>2. If there is no file, is there a directory with the module name? If so, import all .d files in that directory. Check wether any module statements inside the files refer to the wrong module. If they do it should be an error. Stop if all files are imported successfully.
>
>3. If there is neither a file nor a directory with the module name then we have an error.

This is EXACTLY the module importing scheme that I've wanted to see from day 1.

--Benji

I've been thinking about this overnight (yes, I'm a sad git that designs in his sleep), and I think we'll have a long hard look at a RegistryCursor module, so there'd be no process/thread global registry position, but rather you can declare a cursor, and have all the analagous file system operations, .., etc.


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkf76s$1ll9$1@digitaldaemon.com...
> Helmut Leitner wrote:
> > The registry is very much like a file system, so the interface to it might profit from similarities.
> >
> > Typically you put information about your software into a part of the registry. Set your "current working directory" and work relative to this.
> >
> > I would like to write:
> >
> >    import windows.registry;
> >    ...
> >
Registry.SetDirectoryCurrent("\\HKEY_CURRENT_USER\\Software\\Synsoft\\App");
>
> I see one problem with that: the current directory would be global. That is one thing I have always hated about the filesystem as well. If you write a library you need to make sure not to modify the current directory because the application might need it to be unchanged. If you write an application you have to account for the fact that a library might change the current directory, because not all library authors stick to the same rules.
>
> So I usually end up not using the current directory at all. Instead I store the reference path somewhere and manually convert all relative paths to absolute paths before I call a filesystem function.
>
> The problem could be solved if there was a Registry object so that the current directory could be local to those parts of the software that use the same object.
>
> Hauke
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkfs0e$ar5$1@digitaldaemon.com...
> I've been thinking about this overnight (yes, I'm a sad git that designs
in
> his sleep)

Heh. Me too (and in the shower, but that's another issue ;)). Best time for
software design.

> and I think we'll have a long hard look at a RegistryCursor
> module, so there'd be no process/thread global registry position, but
rather
> you can declare a cursor, and have all the analagous file system
operations,
> .., etc.

I like that idea!

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkftbr$e3b$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkfs0e$ar5$1@digitaldaemon.com...
> > I've been thinking about this overnight (yes, I'm a sad git that designs
> in
> > his sleep)
>
> Heh. Me too (and in the shower, but that's another issue ;)). Best time
for
> software design.
>
> > and I think we'll have a long hard look at a RegistryCursor
> > module, so there'd be no process/thread global registry position, but
> rather
> > you can declare a cursor, and have all the analagous file system
> operations,
> > .., etc.
>
> I like that idea!

Me too. I think I feel an article coming on ....


-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac       (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"But if less is more, think how much more more will be!" -- Dr Frazier Crane

----------------------------------------------------------------------------
---

Cursors is another way of looking at iterators.  Iterators break down in complex data structures because it's difficult to figure out what "next" should be, and there may be no total ordering (think graphs, networks). Cursors allow you to go more than one way.  You could imagine a graph cursor overloading operator [] and operator length.  Or it could provide up,down,left,right methods.  Meanwhile it's easy to refer to the object it's pointing to currently.

It would also be interesting if the cursor could morph into different types as it transitions across edges.  One time it'd be a "branch" cursor that let you pick among branches (and the owner) and next time it'd be a "leaf" cursor that could only go back to the owner.

Sean


"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkftbr$e3b$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkfs0e$ar5$1@digitaldaemon.com...
> > I've been thinking about this overnight (yes, I'm a sad git that designs
> in
> > his sleep)
>
> Heh. Me too (and in the shower, but that's another issue ;)). Best time
for
> software design.
>
> > and I think we'll have a long hard look at a RegistryCursor
> > module, so there'd be no process/thread global registry position, but
> rather
> > you can declare a cursor, and have all the analagous file system
> operations,
> > .., etc.
>
> I like that idea!
>
> Hauke

Waaaayyyyyyyyy above my head.

:)

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkgli7$2sv1$1@digitaldaemon.com...
> Cursors is another way of looking at iterators.  Iterators break down in complex data structures because it's difficult to figure out what "next" should be, and there may be no total ordering (think graphs, networks). Cursors allow you to go more than one way.  You could imagine a graph
cursor
> overloading operator [] and operator length.  Or it could provide up,down,left,right methods.  Meanwhile it's easy to refer to the object
it's
> pointing to currently.
>
> It would also be interesting if the cursor could morph into different
types
> as it transitions across edges.  One time it'd be a "branch" cursor that
let
> you pick among branches (and the owner) and next time it'd be a "leaf" cursor that could only go back to the owner.
>
> Sean
>
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkftbr$e3b$1@digitaldaemon.com...
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkfs0e$ar5$1@digitaldaemon.com...
> > > I've been thinking about this overnight (yes, I'm a sad git that
designs
> > in
> > > his sleep)
> >
> > Heh. Me too (and in the shower, but that's another issue ;)). Best time
> for
> > software design.
> >
> > > and I think we'll have a long hard look at a RegistryCursor
> > > module, so there'd be no process/thread global registry position, but
> > rather
> > > you can declare a cursor, and have all the analagous file system
> > operations,
> > > .., etc.
> >
> > I like that idea!
> >
> > Hauke
>
>

Thanks for the smiley!

Really a cursor is just a fancy iterator.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkgm89$2ugv$2@digitaldaemon.com...
> Waaaayyyyyyyyy above my head.
>
> :)

This thread needs renamed.


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkgli7$2sv1$1@digitaldaemon.com...
> Cursors is another way of looking at iterators.  Iterators break down in complex data structures because it's difficult to figure out what "next" should be, and there may be no total ordering (think graphs, networks). Cursors allow you to go more than one way.  You could imagine a graph
cursor
> overloading operator [] and operator length.  Or it could provide up,down,left,right methods.  Meanwhile it's easy to refer to the object
it's
> pointing to currently.
>
> It would also be interesting if the cursor could morph into different
types
> as it transitions across edges.  One time it'd be a "branch" cursor that
let
> you pick among branches (and the owner) and next time it'd be a "leaf" cursor that could only go back to the owner.
>
> Sean
>
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkftbr$e3b$1@digitaldaemon.com...
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkfs0e$ar5$1@digitaldaemon.com...
> > > I've been thinking about this overnight (yes, I'm a sad git that
designs
> > in
> > > his sleep)
> >
> > Heh. Me too (and in the shower, but that's another issue ;)). Best time
> for
> > software design.
> >
> > > and I think we'll have a long hard look at a RegistryCursor
> > > module, so there'd be no process/thread global registry position, but
> > rather
> > > you can declare a cursor, and have all the analagous file system
> > operations,
> > > .., etc.
> >
> > I like that idea!
> >
> > Hauke