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

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

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\\MainWindowWidth",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\\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

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

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

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

"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

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

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

Good suggestions!