Packaging Rules validations

[Richard Sargent]

I think this is a feature request, because I haven't seen anything to say that it's already in the product.

When I add a packaging rule, such as the following:

aRuleCreationInterface ignoreNoImplementorErrorsForMessageSend: #'gsmyUserProfile' inMethod: #'getInteger:' inClassNamed: #'GbxClassReader'.

It would be nice if there were to tool that could be run against the various #packagingRulesFor: methods to verify that each rule is still relevant.

i.e. If I were to modify the #getInteger method and it no longer used the symbol #'gsmyUserProfile', I could get told of that fact.

The manual process of checking whether there is a packaging rule for each changed method and inspecting the rule along side the method to see if it remains valid is unreasonably tedious and error prone.

A stand-alone tool (some kind of lint checker) or the packager itself checking and reporting on no longer relevant rules are both acceptable approaches.

[Wayne Johnston]

I agree.

Although it could get complicated.

[Richard Sargent]

On Tuesday, September 17, 2019 at 5:15:49 PM UTC-7, Wayne Johnston wrote:

I agree.

Although it could get complicated.

That is true. But, better to have some lint checking rather than none.  (And I do mean reliable lint checking, without false positives.)

For example, #doNotReduceClassNamed: already validates that the named class does exist.

Or, #excludeAllMethodsNamed: doesn't care if there are no implementors when packaging. But, a validator might.

#ignoreExcludedClassReferencesInClassVariable:inClassNamed: verifies that the class and class variable exist, but ignores whether the class variable references an excluded class.

[Mariano Martinez Peck]

Hi Richard, 

Yes, you need to keep packaging rules in sync with the actual code. Pretty similar in the way you need to keep your tests in sync with the code. But I get that in packaging it's more coupled than in tests because you deal with internal implementation of the methods etc. 

So... I will open a case for it but we will have to ponder it if/when we can deal with it. 

Best, 

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/36a8e97e-b4d3-4313-ab80-2fe59d81fe64%40googlegroups.com.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: mp...@instantiations.com

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/