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

David Pennell pennell.david at gmail.com
Mon Dec 1 22:25:25 UTC 2008


How about tagging each legitimate unsent method with a pragma?
e.g.

myUnsentMethod
   <unsentByDesign>
   ^42

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081201/91d37208/attachment.htm


More information about the Squeak-dev mailing list