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


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.


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.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\\MainWindo
wWidth",width); (this

 allows different types)


path=Registry.KeyRetValue("\\HKEY_CURRENT_USER\\Software\\Synsoft.App\\Path"
); (string type only)


width=Registry.KeyRetValueInt("\\HKEY_CURRENT_USER\\Software\\Synsoft.App\\M
ainWindowWidth");

 (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.


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,




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.*"?


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,


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.


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,


 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.


 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;
    ...




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 "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


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



 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


 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

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



 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


 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





 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


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







 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




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 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


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







 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




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.


 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