[squeak-dev] Cleaning up lava code and unsent messages.

Igor Stasenko siguctua at gmail.com
Tue Dec 2 00:41:13 UTC 2008


2008/12/2 David Pennell <pennell.david at gmail.com>:
> How about tagging each legitimate unsent method with a pragma?
> e.g.
> myUnsentMethod
>    <unsentByDesign>
>    ^42

good idea, except maybe naming of pragma.

> You can easily see all of them by using senders of #unsentByDesign (I can't
> spell "legitamately"...), the tags are close to the method being tagged
> rather than elsewhere and you don't have to worry about packaging
> boundaries.
> -david
> On Mon, Dec 1, 2008 at 2:20 PM, Edgar J. De Cleene
> <edgardec2001 at yahoo.com.ar> wrote:
>>
>>
>>
>> El 2/22/08 11:01 PM, "Jerome Peace" <peace_the_dreamer at yahoo.com>
>> escribió:
>>
>> > Cleaning up lava code and unsent messages.
>> >
>> > Hi all,
>> >
>> > This was an after thought from my previous post. It
>> > deserved its own topic.
>> >
>> >
>> > Lava code is code left over from historical times
>> > which has no use in the current image and yet no one
>> > is willing to take responsiblity for removing it.
>> >
>> > For the record squeak has historically had about one
>> > sixth of its messages as unsent methods.  Some of
>> > which is lava code others of which are examples,
>> > probes, utilities and tests.
>> >
>> > It would be nice to clean things up so there are no
>> > unsent messages. This could be done simply by creating
>> > a (pseudo-recursive) message
>> > #legitamatelyUnsentMethods (one method say for each
>> > class.) That sends for any legitimate examples, etc.
>> > Then anything that shows up as unsent would be
>> > illegitamate and removeable.
>> >
>> >> From time to time you would look at the implementors
>> > of the legitamatelyUnsentMethods to clean out what no
>> > longer belongs.
>> > a legitamatelyUnsentMethods method would be packagable
>> > if care were take that it mentions only the unsent
>> > methods of that package.
>> >
>> > My proposal is that package maintainers should take
>> > the responsibility for doing this in their own
>> > packages and the release team should reject any code
>> > that contains unsent messages. An Sunit test could be
>> > provided to check.
>> >
>> > I am also hoping to recruit those who would be willing
>> > to sort out the unsent messages in core packages and
>> > either write legitamatelyUnsentMethods methods for
>> > them or flag them as lava code for removal. It is a
>> > good way to gain an insight into a lot of squeak code
>> > while helping the community.
>> >
>> > If this task appeals to you please start it by
>> > planting a seed on mantis.
>> >
>> > Yours in service and curiosity, --Jeorme Peace
>> >
>> >
>> As part of previous Release Team I support Jerome.
>> Also reminds he (and all) Pavel have less unimplemented in his works, so
>> some could be learn and moved to current release.
>>
>> Because we have one ... Or not ?
>>
>> Edgar
>>
>>
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Squeak-dev mailing list