Naming conflict between Store.Registry and Registry namespace

Mit freundlichen Grüssen

Thomas Brodt
PORaBo Consulting
Tel. +41 71 677 20 50
Fax. +41 71 677 20 59
http://www.porabo.ch

Dear Travis,
    I provide a comment below after one of yours.

  

I wrote the original versions of Registry. I don't mind, in fact am  
all too glad, to see someone step forward and take an active  
maintenance role with it. Some intermingled thoughts.

On Feb 2, 2010, at 11:00 PM, Joachim Geidel wrote:

 

    

Dear all,

There is a naming conflict between Store.Registry and the Registry  
namespace
of the Registry package (an unsupported contribution to  
VisualWorks). Niall
Ross made me aware of this potential conflict last October, but it  
didn't
seem likely that there would be a real issue. However, I ran into an
Exception where somehow Store.ComparePackages>>packageIsInImage  
resolved the
variable name "Registry" as the Registry namespace instead of
Store.Registry. I don't know yet why this happened. It may depend on  
the
order in which I loaded Registry and other packages/parcels.
   

      

This seems unfortunate. I think if I were doing it over gain, I'd just  
rename it. To something like WinRegistry. Or MSRegistry.  
Win32Registry. There are all kinds of Registries out there now days.  
Make it crystal clear that this is specififcally the Microsoft Windows  
Registry. Not something that is longer, but still vague (e.g.  
RegistryInterface, RegistrySystem, etc).

 

    

So this will have to be fixed. Now that Win32SystemSupport has  
enhanced
registry access methods using the wide string API, this would also  
be a good
time to redirect Registry's system calls to Win32SystemSupport  
instead of
having a completely separate external interface class. I'll see what  
I can
do about it.
   

      

At the time, there was a very good reason for this. It became a  
practice that I follow today. I found, that extended existing external  
interfaces was problematic and introduced undesired coupling. By doing  
it separate, I got rid of a whole bunch of parcel extension method  
problems with DLLCC that I could never hunt and chase down. And I got  
out of the problem of what happened when other people extended the  
same class, with possibly conflicting extensions. Basically, by  
keeping it small and isolated and simple, I was guaranteed a black box  
that just worked well for a long time. I've followed this same  
practice with any library I've written that has more than a trivial  
(i.e. one or two simple functions) interface with the OS. Cairo,  
OSTimeZone, etc. You'll have to do as you see fit... if I were  
actively maintaining it myself, I know I'd keep it as it's own  
separate interface and not pile more stuff on top of Win32SystemSupport.
 

    

While progressing 52471 and related ARs last year, Martin and I noticed 
issues to do with extension methods on ExternalInterface classes that we 
_believed_ were an effect of trying to make our build process invoke 
#fillDefineCachesWithValues in a class-oriented instead of 
package/extension oriented manner.  Full generic resolution was deferred 
till 7.8.

These extend-ExternalInterface-class problems may also relate to AR 
58099, which discusses cases in which complex chains of typedefs need 
more #recompileMethods calls than Store provides by default (new Store 
that is - old Store even more assumed a single pass would suffice which 
was not always the case).

DB2EXDI shows a postLoad action that solves a problem in a specific 
case.  Meanwhile, the general solution is being worked on.

Relevance to this:  I think if Joachim wanted to extend an 
ExternalInterface class instead of having a separate one, he'd be able 
to make it work, but he might want to check DB2EXDI and read the 
relevant bits of those AR texts.

  

Before changing the package, I would like to know how important  
backward
compatibility is in this case. Would anybody have a problem if a new  
version
of the Registry package were not 100% backward compatible? Does  
anybody use
the file based registry at all? Would it be okay to replace the  
current
implementation for file based registries, which is based on a  
directory
hierarchy, by an implementation which stores the whole registry  
contents in
a single XML file?
   

      

At the time I did the file based one, the software it was primarily  
written for was Windows. And the multi file approach was simply the  
simplest thing that could work. XML wasn't a major byword yet either.  
But one or two people there were dabbling with Linux. So it gave a  
cheesy way to not have to change all of that, but do development work  
off of Windows.

I would share your suspicion that it's not all that used, and doesn't  
really matter what the storage mechanism is there. In fact, you could  
probably just drop it all together. When someone really needs to  
simulate the abomination known as the registry on other platforms, let  
them add it in an extension package, in the way that suits them best.

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


 

    

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc