Packaging Rules validations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging Rules validations

Richard Sargent
Administrator
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/78ec4096-7873-4da5-ad27-ae215d73be02%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging Rules validations

Wayne Johnston
I agree.

Although it could get complicated.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/0bc3b6ed-27f9-4cbb-8343-7f2e4d46b06f%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging Rules validations

Richard Sargent
Administrator


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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/36a8e97e-b4d3-4313-ab80-2fe59d81fe64%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging Rules validations

Mariano Martinez Peck-2
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, 


On Tue, Sep 17, 2019 at 9:45 PM Richard Sargent <[hidden email]> wrote:


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.

--
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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibFJB97bKihjjKX6E__19HYwTD5QanoA1a1bumTFo27Fdg%40mail.gmail.com.