Dynamic fields in MessageSendRecorderExtension inconvenient with respect to VCS

[LinqLover]

The fact that dynamic fields in the MessageSendRecorderExtension class are implemented as new methods added to the class is quite inconvenient when working with changesets, Monticello versions, or any other version control system because normal usage of the recorder tool generates code changes.

Is it correct that this implementation approach was chosen for optimization reasons for the quick sends? Can we (silently) call #removeAllFields whenever a recording was finished to keep the image clean? I'd be happy to do this if you like it :-)

[marceltaeumel]

InstVar access is orders of magnitude faster than dictionary lookup. Removing those fields after recording would destroy the data in the records you just created. :-) One could put those fields into the "*autogenerated" protocol. Would that help:

[LinqLover]

One could put those fields into the "*autogenerated" protocol. Would that help:

Yes, this would probably be the most elegant solution. We could also call the protocol '*UserObjects-fields' or so instead to reduce the number of packages, but either of them would be fine.

I can submit a PR if you like :-)

[marceltaeumel]

Squeak Trunk knows already about that "autogenerated" package. See Preferences class. Another existing class category would be "UserObjects", which will be cleared during release building.

[LinqLover]

Should we merge them in the Trunk, too? What's their semantic difference?

[marceltaeumel]

"UserObjects" is for classes, originates from Etoys for its uni-classes. "Autogenerated" is for methods. Granularity is the difference.

[LinqLover]

Alright, I'll submit a PR soon unless you preempt me.