Smalllint reporting "Methods with full blocks"

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

Smalllint reporting "Methods with full blocks"

Ian Oldham-5
since upgrading to DPRO5.1pl1 running smalllint on my projects reports loads
of "Methods with full blocks". One example of a method that is reported in
this way is:
    cmPause
Cursor wait showWhile: [environment pause]

This behaviour didn't happen in DPRO5.0pl3 as far as I remember, and
checking in the smalllint rules for 5.0 I noticed that "Methods with full
blocks" didn't exist as a smalllint rule. Has this rule been added in 5.1 or
had I removed it from my 5.0 image?. I doubt the latter because I couldn't
find any references to the topic in the newsgroup archives so I doubt I
would have removed it off my own bat. Can anyone shed any light on this
situation?

    regards, Ian


Reply | Threaded
Open this post in threaded view
|

Re: Smalllint reporting "Methods with full blocks"

Blair McGlashan-2
Ian

You wrote in message news:[hidden email]...
> since upgrading to DPRO5.1pl1 running smalllint on my projects reports
loads
> of "Methods with full blocks". One example of a method that is reported in
> this way is:
>     cmPause
> Cursor wait showWhile: [environment pause]
>
> This behaviour didn't happen in DPRO5.0pl3 as far as I remember, and
> checking in the smalllint rules for 5.0 I noticed that "Methods with full
> blocks" didn't exist as a smalllint rule. Has this rule been added in 5.1
or
> had I removed it from my 5.0 image?. I doubt the latter because I couldn't
> find any references to the topic in the newsgroup archives so I doubt I
> would have removed it off my own bat. Can anyone shed any light on this
> situation?

I think it was disabled in 5.0 because, in effect, that Smalltalk-80 style
blocks D5 are always "full", and so it always fires against methods with
blocks.
For maintenance reasons 5.1 now shares the same Refactoring engine and
Smalllint code as the still-in-development D6. Since D6 implements true
block closures, and has all the usual block optimisations such as clean and
copying blocks, the lint rule is useful there and has been re-enabled. The
effect on D5.1 was unintentional, sorry. The lint rule is telling you the
truth, but there isn't anything you can do to modify the code to make it
shut up (unlike D6), so you might like to evaluate the following to disable
it:


(MethodCategory name: 'miscellaneous') removeMethod: (BlockLintRule class
compiledMethodAt: #fullBlocks)

Regards

Blair