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






      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs