[GemStone-Smalltalk] Class names and VisualWorks namespaces

Mon Nov 23 18:10:23 PST 2020

Thanks Martin,

As you noted, since I have many classes with the same base name I can’t use the automatic tools at all.  My philosophy is that I need “automatic” in the sense that my development cycle shouldn’t be significantly impacted by the fact that some classes have instances stored in Gemstone.  I should be able to continue to create, modify and rename persistent classes in client Smalltalk and generally not worry about Gemstone except migration-related issues.  In addition, the process of populating the class hierarchy in server Smalltalk should be easily reproducible (this was also the advice in the GBS User’s Guide).  My idea was to create a tool that you give a collection of classes and it:

1) makes an assessment of the following:
1a) which namespaces are missing on the server (I map VW namespace to Gemstone SymbolDictionary in the user’s symbol list)?
1b) which classes are missing on the server?
1c) which classes have structural difference between the Gemstone version and the client version?
1d) given session parameters, which connectors are missing or incorrect?

2) Given an assessment, correct as many problems as possible automatically

The reason for the two step process is that you might find that you need to manually fix some of the problems.  For example, in 1b a “missing server class” might actually be a case where you renamed a client Smalltalk class.

I have attached code but, frankly, it looks like amateur hour.  I apologize but I got lost in a maze of private methods that didn’t quite do what I needed.  I finally just gave in and used the private methods in hopes of not being burnt in the next Gemstone release.  There are problems remaining:

1) the method GbsSession>>createServerClassFor:inDictionaryNamed:usingName:generateConnector: uses GbsSession>>gemStoneClassFor: to find the superclass of the class you’re trying to create.  If the class you’re creating’s superclass has not been mapped, the latter method falls back on searching for a SymbolDictionary containing the appropriately named class which can result in the wrong superclass being found.

2) I some cases where I probably should, I don’t consult the session class cache so my code seems to be working on the assumption that their are no classes mapped in the session.  I think this /might/ be OK as I’d only use this tool on a fresh session and most of the (private) methods I use, consult the cache as needed.  Honestly I can’t tell how big a problem this is.

3) I’m calling the following private methods:
   GbsSession>>createServerClassFor:inDictionaryNamed:usingName:generateConnector: 
   Object>>gbxDelegate
   … maybe more that I can’t remember...

But, I was able to use the class side methods as such:

   assessment := GemstoneClassBuilder assessPundlesNamed: #(mybundle myotherbundle etc).
   “Inspect assessment to make sure you’re not going to do something stupid”
   GemstoneClassBuilder correctAsssessment: assessment.

...and it populated Gemstone with 1000+ classes….well, actually I had to run the same code a few times before it decided that all of the required Gemstone classes existed.  But, the result looks OK.  There are a few classes that have multiple versions (maybe in different SymbolDictionaries?) but I feel like I’m close.

I’m a bit embarrassed to share this code…I’m kind of hoping someone will simply tell me that I’ve missed an obvious ways to do this. Criticism, constructive or otherwise, is welcomed.

Best,

David

> On Nov 23, 2020, at 6:34 PM, Martin McClure <martin.mcclure at gemtalksystems.com> wrote:
> 
> Hi David,
> 
> A bit of additional information that might be useful. As Richard says, GBS currently has no way to control which namespace automatically-generated classes are placed in. However, you can connect an existing class in any VW namespace by specifying an environment to the class connector.
> 
> Regards,
> -Martin
> 
> On 11/2/20 10:03 AM, David Shaffer via GemStone-Smalltalk wrote:
>> Thanks Richard, I guess I was just looking for confirmation that I had to write this code myself.  At the moment I’m mapping VW namespaces to GS symbol dictionaries (replacing “.” with __ and ignoring containment of one namespace inside another).  This keeps classes unambiguous on the server.  Code attached “kind of” works and comments are welcomed but not expected ;)  Now I have to sort out all of the magic in GbsSession>>createGemStoneClassFor:copyOldVersion: and GbsSession>>doesClientClass:matchServerClass: since those methods handle lots of special cases (class already exists with same/different structure etc) but are, unfortunately, interactive.
>> 
>> (Sorry about the crappy Topological sort…it will need to be revisited if you’re publishing a large number of classes).
>> 
>> Best,
>> 
>> David
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Nov 2, 2020, at 12:51 PM, Richard Sargent <richard.sargent at gemtalksystems.com <mailto:richard.sargent at gemtalksystems.com>> wrote:
>>> 
>>> On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com <mailto:gemstone-smalltalk at lists.gemtalksystems.com>> wrote:
>>> Am I misunderstanding or does GemBuilder for VisualWorks ignore VisualWorks namespaces when automatically generating server classes and automatically creating connectors?  
>>> 
>>> From the GBS for VisualWorks documentation:
>>> GemBuilder deposits automatically generated GemStone server classes in the
>>> GemStone symbol dictionary UserClasses, which it creates if necessary.
>>> Automatically generated client Smalltalk classes are deposited in the current
>>> package. 
>>> With respect to the "ignore VisualWorks namespaces" part of your question, I think the best way to answer it is "pretty much".
>>> 
>>> As noted in the documentation, this automatic class generation is intended as a developer convenience. It is still best to deploy code to each environment in advance of running the application and to predefine the class connectors that could have a conflict or otherwise be unreachable by name lookup.
>>> 
>>> 
>>> Best,
>>> 
>>> David
>>> 
>>> _______________________________________________
>>> GemStone-Smalltalk mailing list
>>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk <https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
>> 
>> 
>> 
>> _______________________________________________
>> GemStone-Smalltalk mailing list
>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk <https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20201123/606f22a8/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GemstoneAssessment.st
Type: application/octet-stream
Size: 9494 bytes
Desc: not available
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20201123/606f22a8/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20201123/606f22a8/attachment-0003.htm>