How to submit refactorings (or: Removing PWS)

danielv at netvision.net.il danielv at netvision.net.il
Fri Nov 15 12:57:56 UTC 2002


If think we are in violent agreement then. Lets review -

* Code is refactored to make a complete package that requires no other
code changes to load/unload.
* Refactoring is posted for feedback (on list or SM) as needed.
* When it's acceptable the code is inserted into update stream, so that
code becomes removable using "remove category" in the simple case or DVS
if there are class extensions.
Then (Some unspecified time after the package starts living in SM...)
* Update is issued that performs the remove, asking the user if he wants
to reload from SM, or leave his version loaded (in case he has
modifications).

Comments?

If none and the it's ratified by the Guides, this will become our
current policy for removing things from the image, and I'll put it on
the swiki and expand on the details, and we'll do it to PWS first, and then
to whatever we get good unload code for.

Daniel

Julian Fitzell <julian at beta4.com> wrote:
> I think we got wires crossed... I talked to Avi about this a bit more 
> off-list.  I wasn't saying that any packages could not be encompassed as 
> DVS packages or that DVS wouldn't be able to remove them.  I was just 
> saying that a DVS package would not be capable of doing the initial 
> removal from the image in their current state.  Once the image is fixed 
> and the package created and (possibly) refactored as necessary, there is 
> no problem.  I was just arguing that the update stream will have to be 
> modified to support these removals - we can't just do it externally with 
> packages.
> 
> I, like many others it seems, would love the see updates that remove 
> code (code that is easily installable from SM) but that's another issue, 
> really.
> 
> Hope that's clearer,
> 
> Julian
> 
> danielv at netvision.net.il wrote:
> 
> > As far as my imagination serves me right now, Smalltalk is powerful
> > enough that any connection can be created/managed using class extensions
> > or registrations (as you say "...less directly coupled..").
> >
> > The problem of SystemDictionary remove scripts could be handled by
> > either removing all references to PWS (since it is now implicitly
> > removable, by being a DVS package that isn't neither broken, or depended
> > on), or using a registry for thing that want to be discardable (if
> > there's an added value for it).
> >
> > Of course my imagination is a limited, treacherous thing, and I'm sure
> > you or the future will soon prove it so ;-)
> >
> > Daniel
> >
> > Julian Fitzell  wrote:
> >
> > >Avi Bryant wrote:
> > >
> > >
> > >>On Fri, 15 Nov 2002 danielv at netvision.net.il wrote:
> > >>
> > >>
> > >>
> > >>>My point there was that the removals should be separate in time 
> > from the
> > >>>point where the package is made removable.
> > >>>
> > >>>Assuming we eventually want the image to be actually smaller, we'll 
> > need
> > >>>to remove them in updates at some point, no? (after adequate warning,
> > >>>and the remove can be confitional on the users not having installed the
> > >>>package explicitly from SM, and so forth).
> > >>>
> > >>>But I see not rush - the important thing is to make things cleanly
> > >>>remov*able*, as outlined.
> > >>>
> > >>>Right?
> > >>
> > >>
> > >>Yes, and in fact, once the packages are clearly delineated in the image
> > >>(ie, through PackageInfo's naming conventions) a removal script probably
> > >>isn't even necessary - just tell DVS to unload the package (or at least
> > >>get it to generate the removal script for you).
> > >>
> > >>Avi
> > >
> > >That can't be a complete solution though.  What about the stuff that
> > >needs to be removed from SystemDictionary for PWS, for example?  That
> > >should be in the DVS package so it won't be removed by DVS, etc. It may
> > >also involve changing other methods that depend on the package being
> > >removed to be less directly coupled, or whatever... I don't think you
> > >can count on DVS doing the complete removals from the base image.
> > >
> > >Julian
> > >
> > >--
> > >julian at beta4.com
> > >Beta4 Productions (http://www.beta4.com)
> >
> >
> 
> 
> -- 
> julian at beta4.com
> Beta4 Productions (http://www.beta4.com)



More information about the Squeak-dev mailing list