Smalltalk › Instantiations

Packaging Rules validations

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Richard Sargent

Packaging Rules validations

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.

Wayne Johnston

Re: Packaging Rules validations

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.

Richard Sargent

Re: Packaging Rules validations

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.

Mariano Martinez Peck-2

Re: Packaging Rules validations

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.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

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

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

--
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.