www.digitalmars.com         C & C++   DMDScript  

D - Library naming conventions

reply "Matthew Wilson" <matthew stlsoft.org> writes:
Hi chaps and chappettes [note: not sure we have any chappettes, actually]

I want to solicit your opinion on some naming stuff.

I am preparing the registry library, and it's forming into the following
three parts:

1. synsoft.win32. reg (which will be D.win32.reg I expect, once it's in
Phobos). This is the set of classes Registry, Key, Value, KeySequence (for
freaching subkeys) and ValueSequence (for freaching values). This stuff is
complete in terms of the read-only functionality, but there is no
reg-editing functionality yet, and is available now for testing/comment at
http://synsoft.org/d.html. It is implemented in terms of 2 & 3, as follows

2. synsoft.win32.regutil (=> D.win32.regutil). This is a set of standalone
functions that operate on registry keys, e.g. to create a given value for a
given subkey of a given root key, as in

  Reg_CreateValue(HKEY root, char[] subKey, char[] valueName, uint value);
  Reg_CreateValue(HKEY root, char[] subKey, char[] valueName, char[][]
value);

3. 2 will be implemented on top of a set of useful and well-tested C/C++
functions that I'm porting over to D. These will operate in terms of C
types, i.e. char * rather than char[], void * rather than a particular value
data format.


My question is, when there's a set of functions with a D nature, and an
associated set of functions that talk C, has anyone established any naming
convention, in particular to disambiguate one set from the other? I'd
welcome thoughts on this.

A broader issue pertains to the naming of function suites, as opposed to
class libraries. I'm very happy with the D.win32.reg class names, and their
method names, e.g. Key.CreateSubKey(). However, when we're talking about a
module comprised of free functions, the picture is less clear. One option
would be to name things in D.win32.regutil as CreateValue, CreateSubKey(),
etc. But this is pretty vague. It's not difficult to conceive of several
APIs that would provide a CreateValue() function, leading to all kinds of
nasty confusion. The trend in C++ is away from such things and back to the
simple C-way of doing Reg_XxxYyyy, and I prefer that myself, but want to get
all your thoughts so as to avoid (or at least discourage :) ) complaints
about the reg libs.

Matthew
Sep 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkdos6$1pn2$1 digitaldaemon.com...
 My question is, when there's a set of functions with a D nature, and an
 associated set of functions that talk C, has anyone established any naming
 convention, in particular to disambiguate one set from the other? I'd
 welcome thoughts on this.

 A broader issue pertains to the naming of function suites, as opposed to
 class libraries. I'm very happy with the D.win32.reg class names, and

 method names, e.g. Key.CreateSubKey(). However, when we're talking about a
 module comprised of free functions, the picture is less clear. One option
 would be to name things in D.win32.regutil as CreateValue, CreateSubKey(),
 etc. But this is pretty vague. It's not difficult to conceive of several
 APIs that would provide a CreateValue() function, leading to all kinds of
 nasty confusion. The trend in C++ is away from such things and back to the
 simple C-way of doing Reg_XxxYyyy, and I prefer that myself, but want to

 all your thoughts so as to avoid (or at least discourage :) ) complaints
 about the reg libs.

Rather than doing a Reg_ prefix, how about: struct Reg { static XxxYyyy() { } } and then access it like: Reg.XxxYyyy() ? I.e. use the struct as a 'name space'.
Sep 19 2003
next sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
Walter wrote:
 
 Rather than doing a Reg_ prefix, how about:
 
     struct Reg
     {
         static XxxYyyy() { }
     }
 
 and then access it like:
 
     Reg.XxxYyyy()
 
 ? I.e. use the struct as a 'name space'.

I suggest to replace "Reg" and "regutil" by "Registry" and "registry". These functions aren't that often used that they justify abbreviations. So: import synsoft.windows.registry import windows.registry would read better. IMHO. 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"); Registry.KeySetValue("Path","...."); Registry.KeySetValue("MainWindowWith",600); Registry.DeleteKey("Anything"); ... Registry.KeyGetValue("\\HKEY_CURRENT_USER\\Software\\Synsoft\\App\\Main indowWidth",width); (this allows different types) path=Registry.KeyRetValue("\\HKEY_CURRENT_USER\\Software\\ ynsoft.App\\Path"); (string type only) width=Registry.KeyRetValueInt("\\HKEY_CURRENT_USER\\Software\\Synsoft.App\\MainWindowWidth"); (explicit int return type) Registry.SetDirectoryCurrent("\\HKEY_CURRENT_USER\\Software\\Synsoft\\App"); width=Registry.KeyRetValue("App.MainWindowWidth"); Typically I like some abbreviations for words that are often used: Val = Value Dir = Directory Del = Delete Cur = Current but that's a matter of taste. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F6AC39F.E61CD488 hls.via.at...
 Walter wrote:
 Rather than doing a Reg_ prefix, how about:

     struct Reg
     {
         static XxxYyyy() { }
     }

 and then access it like:

     Reg.XxxYyyy()

 ? I.e. use the struct as a 'name space'.

I suggest to replace "Reg" and "regutil" by "Registry" and "registry".

I agree that synsoft.win32.reg / regutil are unnecessarily small. I always prefer to not contract. The only override to that rule is to "fit in" with what everyone else does. When I got into D, it seemed like everyone was using such contractions. I think when I rework them the next time, I'll dispense with the contractions, and give them proper names. The symbol Registry is already used as a class, so even if it will work as a module name, I think doing so would be a mistake. I think what is reg will be Registry, and I'm taking suggestions as to what will become of regutil. This is one of the things I really hate about D's module system. I would like to put all the registry things I'm talking about into one module, i.e. (synsoft/D).win32.registry. But I can't, unless I put them all in one file. Hence the nasty kuldge of .registry & .regutil. Why can't modules be the directory, rather than the file? Sob, sob.
 These functions aren't that often used that they justify abbreviations.
 So:

     import synsoft.windows.registry

It'll be synsoft.win32.registry in the next version, and I expect the one after that'll see it in Phobos, so then it'll be D.win32.registry I guess.
     import windows.registry

What's the root? Just "windows.*" doesn't seem appropriate. Things should either be in the standard library, i.e. begin with "D.", or belong to someone/something.
 would read better. IMHO.

 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.KeySetValue("Path","....");
    Registry.KeySetValue("MainWindowWith",600);
    Registry.DeleteKey("Anything");
    ...

wWidth",width); (this
 allows different types)

); (string type only)

ainWindowWidth");
 (explicit int return type)

    width=Registry.KeyRetValue("App.MainWindowWidth");

 Typically I like some abbreviations for words that are often used:
    Val = Value
    Dir = Directory
    Del = Delete
    Cur = Current
 but that's a matter of taste.

These are interesting ideas. I can't assimilate them into the reg api right now, but maybe when the first version is complete, and people are using/testing/slagging it, we can think about this type of thing. I'll tell you right now, though, that the absence of a native RegGetCurrentDirectory() function means that we'd have to manually track the current key path. It's possible, but it'd be extra work. I'd have to have more than just you, Helmut, important though you are, asking for this before doing it. Of course, once the Reg library is complete, there's nothing stopping you writing your own RegistryCursor library over the top of it. ;)
Sep 19 2003
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew Wilson wrote:
 This is one of the things I really hate about D's module system. I would
 like to put all the registry things I'm talking about into one module, i.e.
 (synsoft/D).win32.registry. But I can't, unless I put them all in one file.
 Hence the nasty kuldge of  .registry & .regutil.
 
 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 :(. Not being able to put a large number of global functions in one module without creating an unreadable mess is one problem. Another one (and a more important one, I think) is the way "friend" classes work. As I understand it, classes are implicitly friends (i.e. can access each other's protected members) when they are in the same module. I like this concept in general, but the one-file restrictions creates a problem. I like to have one class per file. That way imports can be specific to each class and there is no need to ever search for the file that contains the implementation of a class you want to modify. That doesn't work anymore if I need to make two classes friends. Ok, friends are only used occasionally, but sometimes you just need them. I would HATE having to put two classes into the same file just to make them friends. That would make it impossible to have any consistent mapping from classes to files. Because of this, I would also much prefer to have modules be directories instead of files. A related question: is it possible to use wildcards to import several modules/files at once? Something like "import mylib.*"? Hauke
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bker1v$kos$1 digitaldaemon.com...
 Matthew Wilson wrote:
 This is one of the things I really hate about D's module system. I would
 like to put all the registry things I'm talking about into one module,


 (synsoft/D).win32.registry. But I can't, unless I put them all in one


 Hence the nasty kuldge of  .registry & .regutil.

 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 :(. Not being able to put a large number of global functions in one module without creating an unreadable mess is one problem. Another one (and a more important one, I think) is the way "friend" classes work. As I understand it, classes are implicitly friends (i.e. can access each other's protected members) when they are in the same module. I like this concept in general, but the one-file restrictions creates a problem. I like to have one class per file. That way imports can be specific to each class and there is no need to ever search for the file that contains the implementation of a class you want to modify. That doesn't work anymore if I need to make two classes friends. Ok, friends are only used occasionally, but sometimes you just need them. I would HATE having to put two classes into the same file just to make them friends. That would make it impossible to have any consistent mapping from classes to files. Because of this, I would also much prefer to have modules be directories instead of files. A related question: is it possible to use wildcards to import several modules/files at once? Something like "import mylib.*"?

Agree with everything you say, apart from wildcard imports. Hate them. Sloppy, unmaintainable, fragile, make instrumentation all but impossible.
Sep 19 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Sep 19 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
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
Sep 19 2003
parent "Walter" <walter digitalmars.com> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:lq8mmvsjdqcn0g7okcqjb7u77nc73jjssu 4ax.com...
 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.

Unfortunately, there are some problems with this. Suppose there are two files in the abc module named foo.d and bar.d. They won't know about each other, so they cannot refer to each other. The other problem is the module constructors - if each one has a module constructor, they wind up having name clashes. Perhaps these are resolvable, but at the moment they're a problem.
Nov 01 2003
prev sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message news:bken87

 This is one of the things I really hate about D's module system. I would
 like to put all the registry things I'm talking about into one module,

 (synsoft/D).win32.registry. But I can't, unless I put them all in one

 Hence the nasty kuldge of  .registry & .regutil.

 Why can't modules be the directory, rather than the file? Sob, sob.

Well, Dig let you import the module main which only have import statements for the modules that do the real work. module main; import foo; import bar; import foo2; import etc; Might be a solution? Lars Ivar Igesund
Sep 19 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
news:bketfa$qnf$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message news:bken87

 This is one of the things I really hate about D's module system. I would
 like to put all the registry things I'm talking about into one module,

 (synsoft/D).win32.registry. But I can't, unless I put them all in one

 Hence the nasty kuldge of  .registry & .regutil.

 Why can't modules be the directory, rather than the file? Sob, sob.

Well, Dig let you import the module main which only have import statements for the modules that do the real work. module main; import foo; import bar; import foo2; import etc; Might be a solution?

I've not tried this. It may well be a solution. But I can't think of a reason why directories cannot be the module, and can't recall if this was ever discussed to a conclusion point previously. Walter ?
Sep 19 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
Good suggestions!
Sep 19 2003
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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;
    ...


 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

Sep 19 2003
parent reply "Hauke Duden" <H.NS.Duden gmx.net> writes:
"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

 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

 you can declare a cursor, and have all the analagous file system

 .., etc.

I like that idea! Hauke
Sep 19 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"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

 his sleep)

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

 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

 you can declare a cursor, and have all the analagous file system

 .., 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 ---------------------------------------------------------------------------- ---
Sep 19 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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

 his sleep)

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

 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

 you can declare a cursor, and have all the analagous file system

 .., etc.

I like that idea! Hauke

Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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

 overloading operator [] and operator length.  Or it could provide
 up,down,left,right methods.  Meanwhile it's easy to refer to the object

 pointing to currently.

 It would also be interesting if the cursor could morph into different

 as it transitions across edges.  One time it'd be a "branch" cursor that

 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



 in
 his sleep)

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

 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

 you can declare a cursor, and have all the analagous file system

 .., etc.

I like that idea! Hauke


Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.

 :)

Sep 19 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
"Sean L. Palmer" wrote:
 Really a cursor is just a fancy iterator.

I don't think so. At least not in the case of the registry. If you put information about your application X into the registry, you just sit in a special niche of the registry tree. And thats it. No iterattion at all. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 20 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
You can move into a key subgroup or out of one, and iterate through keys and
values in a group, no?  This cursor lets you navigate through the tree, no?

"normal" bidirectional iterators can only go forward or backward, not in and
out.  So I'd see a cursor as an extension of the concept of bidirectional
iterator.

Sean

"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F6C0581.DDE396AE hls.via.at...
 "Sean L. Palmer" wrote:
 Really a cursor is just a fancy iterator.

I don't think so. At least not in the case of the registry. If you put information about your application X into the registry, you just sit in a special niche of the registry tree. And thats it. No iterattion at all. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com

Sep 20 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
"Sean L. Palmer" wrote:
 
 You can move into a key subgroup or out of one, and iterate through keys and
 values in a group, no?  This cursor lets you navigate through the tree, no?
 
 "normal" bidirectional iterators can only go forward or backward, not in and
 out.  So I'd see a cursor as an extension of the concept of bidirectional
 iterator.

You can do that, but it's not the typical way how you use the registry. When Matthew talked about a cursor, he didn't mean it that way. When you set a cursor to a "current working directory" then not because you want to use this as an iterator. I don't mind talking about iterators. It just didn't seem to fit in the registry discussion. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 21 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
What, you never enumerate keys in the registry?  ;)  I'm sure they have
something like that inside RegEdit, in the tree view control.

I take your point.  I think I jumped tangents off what the original point
about the registry was about.  So let's end this thread and move it over to
cursors.

Sean

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F6DD2B1.6F43BA3D chello.at...
 "Sean L. Palmer" wrote:
 You can move into a key subgroup or out of one, and iterate through keys


 values in a group, no?  This cursor lets you navigate through the tree,


 "normal" bidirectional iterators can only go forward or backward, not in


 out.  So I'd see a cursor as an extension of the concept of


 iterator.

You can do that, but it's not the typical way how you use the registry. When Matthew talked about a cursor, he didn't mean it that way. When you set a cursor to a "current working directory" then not because you want to use this as an iterator. I don't mind talking about iterators. It just didn't seem to fit in the registry discussion. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com

Sep 22 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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

 overloading operator [] and operator length.  Or it could provide
 up,down,left,right methods.  Meanwhile it's easy to refer to the object

 pointing to currently.

 It would also be interesting if the cursor could morph into different

 as it transitions across edges.  One time it'd be a "branch" cursor that

 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



 in
 his sleep)

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

 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

 you can declare a cursor, and have all the analagous file system

 .., etc.

I like that idea! Hauke


Sep 19 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkeb42$2ku6$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkdos6$1pn2$1 digitaldaemon.com...
 My question is, when there's a set of functions with a D nature, and an
 associated set of functions that talk C, has anyone established any


 convention, in particular to disambiguate one set from the other? I'd
 welcome thoughts on this.

 A broader issue pertains to the naming of function suites, as opposed to
 class libraries. I'm very happy with the D.win32.reg class names, and

 method names, e.g. Key.CreateSubKey(). However, when we're talking about


 module comprised of free functions, the picture is less clear. One


 would be to name things in D.win32.regutil as CreateValue,


 etc. But this is pretty vague. It's not difficult to conceive of several
 APIs that would provide a CreateValue() function, leading to all kinds


 nasty confusion. The trend in C++ is away from such things and back to


 simple C-way of doing Reg_XxxYyyy, and I prefer that myself, but want to

 all your thoughts so as to avoid (or at least discourage :) ) complaints
 about the reg libs.

Rather than doing a Reg_ prefix, how about: struct Reg { static XxxYyyy() { } } and then access it like: Reg.XxxYyyy() ? I.e. use the struct as a 'name space'.

Several objections. 1. I'm strongly in the Scott Meyers camp, as regards free-functions vs member functions. What I'm talking about are quite unabmiguously free functions, and putting them in a class seems like pure malapropism. They now appear to be member functions, when they're not. They're free functions, that's the point, so we're talking about having them masquerade as something they're not. Quite confusing, I would think, to the poor humble library user. 2. We're already suffering from too many contexts. For example, I cannot define a module synsoft.win32 within which I would like to define Win32 types and also have modules such as synsoft.win32.registry, synsoft.win32.shell, etc. I have to put those things in synsoft.win32.types, a name nothing if not prosaic. This in itself sucks. Now we'd have synsoft.win32.registry.Reg.CreateValue. Yuck.
Sep 19 2003