VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

All of the methods listed are implemented as self subclassResponsibility

EXCEPT the last one:

excludeMethod: #timeout: inClassNamed: #SstSocketDemultiplexor

You can't remove that one since it is the setter for the instance variable. 

The subclass SstWinsockSocketDemultiplexor>>initialize goes boom because the method was removed in the packaging process.

*Steve*

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

*Steve*

Steven,

Am Freitag, 31. August 2018 17:47:20 UTC+2 schrieb Steven LaFavor:

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

well, it is. But for some reason I couldn't decode the posts given about the error at that time ;-)

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

Hmm. isn't that also a change to product code? I know this kind of discussion from several projects and I must say I rather try to integrate the known fixes from Instantiations than go another route. The reason is simple: when you do the next migration, you'll spend two hours or so in a changes Browser anyways, trying to figure out if a change that has been made to product code is still relevant and needs to be integrated in the new version. The picture you see when you apply a suggested (but not yet shipped) fix from Instantiations is easier to understand than some other fix at another place for the very same problem. Changes that clearly have been fixed teh same way we did mak eme much mroe confident than fixes that look as if they attack the same problem that I have solved differently, because there are severa questions to answer during migration:

• do these two code changes reeally solve the same problem?
• Which one is the better fix, takes more side effects into account?
• does our application rely on some side effect of the fix that is not prvided by the other one? Will my applicatio break if I use "their" fix? If so, isn't it better to fix my App than keep that old fix of mine?
  

 This thought process is much too expensive for "just a migration" and is better spent in new features. Migrations between VAST versions are a strange beast for project management. No immediate outcome (the application will just work like before) but a bunch of risks and some cost (you spend a day or two for migrating rather than building new features). The positive side effects of a migration (new features, long-standing bugs are gone) will eventually pay back (I already love 9.1 for its GRVastUtf8Codec and 64 bits VM for lInux alone), but often there is no immediate gain.

Joachim

*Steve*

not sure what you want to say by "esoteric discussions"... in German, this would mean you think my arguments are completele nonsense, unless you wear an aluminium hat and / or believe in an almighty Spaghetti monster... ;-)))

Of course that's alright with me, because we all try to do things the most effective way we can and often there is no objectively correct way.

In the end, if you go for the fix of the Packaging Rules, I am right anyways, no matter what the reasons are ;-)