[Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)

[Daniel Vainsencher]

[very concrete discussion of specific extensions]
Please move this to squeak-dev - more people might be interested, and
SqF is really only for boring process and meta discussions, so they
don't hang around here ;-)

[License]
Goran gave a good reply. Consider this to be like a situation where you
sign a contract that you can only wear tee shirt made by McDonalds. They
currently have a cool promotion where they will make you any shirt you
want, and give it to you for free. Does this make the law reasonable,
considering that their promotions can change?

Squeak's compiler should be modifiable using tools under a quite free
license. If we want to be able to publish images that contain it, it
needs to either be SqueakL or be declared SqueakL compatible, which we
haven't thought about much, yet.

Daniel

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi anthony
> 
> > There are two packages: ContextCleanupPlus-ajh.zip and  
> > ClosureCs-ajh.zip.
> > ContextCleanupPlus cleans up contexts, exceptions, and related  
> > classes.  You
> > can think of it as part of KCP.  I have used it for about a year in my  
> > image,
> > and after a few minor updates here and there, things are running very  
> > smoothly.
> >  I would encourage people to test it just by loading it and going  
> > about their
> > normal business.  Normal operation will test its low-level changes.
> >
> >> What about the SmaCC license issue?
> >
> > ContextCleanupPlus does not depend on SmaCC, only ClosureCs does which  
> > we can
> > be considered after ContextCleanupPlus.  ClosureCs depends on
> > ContextCleanupPlus but not vice versa.
> 
> But ClosuresCs does not depend on SmaCC. It has been generated using  
> SmaCC which
> is different. I do not need to include bison because I use a parser  
> developed with it.
> Or there is something wrong.
> Can you let me know if I'm wrong?
> Stef
> 
> 
> >
> >> Anthony, for some reason includes in this package myriad changes to
> >> existing classes.
> >
> > Of course, cleanup involves changes to existing classes.  If you're  
> > talking
> > about the additional protocol I've added to general classes, below are  
> > the
> > detailed explanations.
> 
> Have you thought of using DVS to mark the extensions that are really  
> linked to Closures, from the
> ones that should be put into the image? Because this would be nice to  
> follow this practice
> because this will help us when we will have packages.
> 
> 
> > I think you will agree they a reasonable, and truly
> > belong as class extensions rather than in user classes where they  
> > would be
> > tedious and less reusable.  I would not be afraid to add these new  
> > protocols
> > especially since they can't affect any existing code.  Note, many of  
> > the users
> > are in ClosureCs and not in ContextCleanupPlus itself.
> >
> > Object>>literalEqual: - Do the receiver and argument represent the same
> > literal.  Note, two objects can be = but not literalEqual: as in  
> > 'anthony' =
> > #anthony, but ('anthony' literalEqual: #anthony) not.
> >
> > Boolean>>asBit - Return 1 for true, 0 for false.
> >
> > Class>>becomeClass: otherClass - Become forward the other class and  
> > fix up the
> > global dictionary and system organization as well.
> >
> > Collection>>collectArray: - Same as collect: except always return an  
> > array.
> 
> This one looks quite strange to me. You are impacting more than 140  
> classes!!
> 
> 
> >
> > CompiledMethod>>headerDescription - Prints out all the components of  
> > the header
> > (numArgs, numLiterals, etc) in a readable format.
> Good, needed
> 
> >
> > LargePositiveInteger>>as31BitSmallInt - Keep my 31 bits the same but  
> > put them
> > in a SmallInt.
> >
> > Number>>extend: - Like #to: except designate the length instead of the  
> > last.
> >
> > OrderedCollection>>bottom,top,pop,push,etc. - stack protocol.
> 
> Sorry but this stuff should not be there. Implement a Stack class.
> Sure an orderedCollection can be used as a stack but....
> 
> Anybody else point of view?
> 
> 
> > SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put 
> > :
> > ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:w 
> > i
> > thIndexDo: - Additional methods that are similar to other methods that  
> > already
> > exist and should be part of the protocol because they are useful.  I  
> > bet many
> > of these have been needed in the past but were coded out the long way  
> > in the
> > user.
> >
> > PositionableStream>>back,current,previous,do:,at:,includes: - Added  
> > helpful
> > methods for stepping back and looking into the collection itself.
> >
> > WriteStream>>insert:,removeNext: - Additional manipulation beside  
> > appending.
> >
> > (The last two additions may not seam appropriate for streams if you  
> > look at a
> > stream like a pipe.  So I could be persuaded to move these to a new  
> > class.  But
> > the rest I believe are very appropriate for their specified classes.)
> >
> > Cheers,
> > Anthony
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month!
> > http://sbc.yahoo.com
> > _______________________________________________
> > Squeakfoundation mailing list
> > Squeakfoundation at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> >
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation