[GemStone-Smalltalk] Bug?

Tue Mar 23 08:29:30 PDT 2021

Thanks Martin,

I decided to go the “class name mangling” direction.  It was easier than I thought.  So now I map VW class names X.Y.Class to X_Y_Class.  Life is good again :). I’ll give GbsNameConnector a try when I have some down time since I would prefer using the same names on both systems.  While VW namespaces and GS symbol dictionaries are different, they seem similar enough to make it work.  In GOODS I created a “class name mapper” whose job it was to map St class names to and from GOODS class name.  This mapper could be plugged into a session so any automatic translation would use the mappings.  I could imagine this would be useful in GS in a couple of situations:

St->GS class generation in the browser could use it
When “generate class connectors” setting is true, connector generation would consult the mapping
When “generate server classes” setting is true, class generation would consult the mapping

The mapping would specify how VW namespaces map to GS symbol dictionaries and how VW class names transform into GS class names.  Some built-in implementations could be:
Namespace ignored (all classes in same SD), St class name = GS class name
Namespace <-> SD, St class name = GS class name
Namespace ignored (all classes in same SD), GS Class name  = mangled St class name to prefix with NS name

This would make it easier for people to avoid the manual “tooling" when they’re getting started in GS but already have complex persistent models.   I’ve attached my class creation tool…it isn’t in great shape because of the fumbling around but it might be useful for reference for people new to GS.

Best,

David

> On Mar 22, 2021, at 10:20 PM, Martin McClure <martin.mcclure at gemtalksystems.com> wrote:
> 
> Hi David,
> 
> I'm sorry to hear you're having problems in this area.
> 
> After some research, I have come to the conclusion that this kind of mapping has never worked in GBS. I'll file a feature request, since it's something that *could* work.
> 
> A possible workaround would be to use GbsNameConnectors with a postConnectAction of #none, instead of GbsClassConnectors. I haven't extensively tested this, but it seems to basically work. I'd appreciate it if you could try that and let us know how well that works.
> 
> Thanks,
> -Martin
> 
> On 3/20/21 2:04 PM, David Shaffer via GemStone-Smalltalk wrote:
>> Here are some things I’ve tried:
>> 
>> 1) Using the “base” VW class name but also setting the environment:
>> 
>> (#{GbsClassConnector} value
>> 		stName: ’ConflictingName'
>> 		gsName: #ConflictingName
>> 		dictionaryName: #GcbNSA) environment: GcbNSA
>> 
>> But then adding the second connector with the same stName removes the first (since GbsNameConnector>>= relies on #clientObjString which only references stName).
>> 
>> 2) Using both the full class name and specifying the environment:
>> 
>> (#{GbsClassConnector} value
>> 		stName: ’GcbNSA.ConflictingName'
>> 		gsName: #ConflictingName
>> 		dictionaryName: #GcbNSA) environment: GcbNSA
>> 
>> This /kind-of/ works.  That is, both connectors stay around as long as I disable connector verification but…when I store instances of the two VW classes in GS, commit, log out then back in, they appear to be instances of the same type.  I think this is a bug in GbsSession>>fetchBehaviorDelegatesForClassConnectors: which seems to ignore the #dictionaryName attribute of the connectors.
>> 
>> I’m dead in the water.  Hacking GbsSession>>fetchBehaviorDelegatesForClassConnectors: is next but I feel like that’s a bad path to go down since there is likely other broken code related to this problem.
>> 
>> -D
>> 
>>> On Mar 20, 2021, at 3:13 PM, David Shaffer <shaffer at SHAFFER-CONSULTING.COM <mailto:shaffer at SHAFFER-CONSULTING.COM>> wrote:
>>> 
>>> Hey folks,
>>> 
>>> I’m a bit stuck on this one…I’m using VW9, GS3.5.4, Gbs8.5, in case it matters.  For testing purposes I have two Dictionaries in my symbol list: #GcbNSA and #GcbNSB each with a class called ConflictingName.  On the VW side I have the same setup but with Namespaces.  I create two class connectors:
>>> 
>>> #{GbsClassConnector} value
>>> 		stName: ’GcbNSA.ConflictingName'
>>> 		gsName: #ConflictingName
>>> 		dictionaryName: #GcbNSA
>>> 
>>> #{GbsClassConnector} value
>>> 		stName: ’GcbNSB.ConflictingName'
>>> 		gsName: #ConflictingName
>>> 		dictionaryName: #GcbNSB
>>> 
>>> But GemStone discards one of them with this error:
>>> 
>>> GbsClassConnector stName: #'GcbNSA.ConflictingName' gsName: #ConflictingName 
>>>          - GbsClassConnector stName: #'GcbNSA.ConflictingName' gsName: #ConflictingName 
>>>          is overriding an existing connection.
>>> GbsClassConnector stName: 'ConflictingName' gsName: #ConflictingName - GbsClassConnector 
>>>          stName: 'ConflictingName' gsName: #ConflictingName is overriding an existing 
>>>          connection.
>>> 
>>> I don’t understand this at all.  While the “gsName” of the two connectors is the same, the dictionaryName is different so they shouldn’t conflict.  Has anyone encountered this?  Or have any suggestions?
>>> 
>>> Basically this makes it impossible to map VW Namespaces to GS Dictionaries…which I was hoping to do as I make extensive use of “conflicting" class names in VW.  I’m left with creating GS class names by mangling all of the VW class names to include namespace info.  Not a path I hopped to go down...
>>> 
>>> -D
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20210323/75c85c94/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GemstoneClassBuilder.st
Type: application/octet-stream
Size: 8843 bytes
Desc: not available
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20210323/75c85c94/attachment-0002.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20210323/75c85c94/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BundleModel-allDefinedClasses.st
Type: application/octet-stream
Size: 420 bytes
Desc: not available
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20210323/75c85c94/attachment-0003.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20210323/75c85c94/attachment-0005.htm>