2016-09-06 15:39 GMT+02:00 Ben Coman <[email protected]>: > Just bumped into a curious thing. I went copy a class with a pool > dictionary... > > FFIExternalStructure subclass: #CXString > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: 'CXStringFlag' > package: 'Libclang' > > and it asked me for the new name, to which I dutifully entered 'CXString2' > after which I was asked... > "CXString2Flag does not exist. Do you want it automatically created?" > > Choosing "No" fails the CXString copy since CXString2Flag does not exist. > Choosing "Yes" produces... > > FFIExternalStructure subclass: #CXString2 > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: 'CXString2Flag' > package: 'Libclang' > > So I'm curious what the reasoning is for making a parallel copy of the > pool dictionary? > > And btw, CXString2Flag gets created in the "Unclassified" package and > fails to copy the methods from the original. > > cheers -ben >
What image version ? We had an issue for a similar case (the class /instance variable names were copied *and* renamed too) 18957 <https://pharo.fogbugz.com/f/cases/18957/Class-copy-should-not-change-the-name-of-the-instance-variables> Class copy should not change the name of the instance variables This was fixed n 60189 (actually, with this change, the pool dictionary definition is just *not* copied but empty, hm, but I think this is better than creating a new with the changed name).
