Re: ContextCleanupPlus-ajh (was: Re: KCP & 3.6)

I know why isSymbol is needed, and don't personally mind your self
approving it. I don't know why Number>>extend: is needed, and probably
won't miss it very much for the next 3 years. 

And more to the point, those extensions Anthony wrote that are generally
useful (asBit, header information printer, around half the OC protocol 
mentioned), deserve to be presented to Squeakers so they'll get used, 
instead of becoming more browser-filler.

Daniel

Marcus Denker <[email protected]> wrote:
> On Sun, Jun 22, 2003 at 03:55:44AM +0200, Daniel Vainsencher wrote:
> > [Additions to various classes...]
> > Note that my problem with these is not that I argue with the usefulness
> > of specific items - I simply don't think that it's appropriate to
> > include them as part of a fix. Why don't you post them one by one to the
> > mailing list for discussion, where people may argue whether they are
> > appropriate. You're saying that something should be part of the class
> > library, defend your opinions on squeak-dev, just like Richard does,
> > method by method, idea by idea.
> > 
> I just self-approved a two-liner I posted six weeks ago. So I would
> estimate that this procedure will take maybe 3 years.
> 
>    Marcus
> 
> -- 
> Marcus Denker [email protected]  -- Squeak! http://squeak.de
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Jun 22 07:46:45 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 24264 invoked from network); 22 Jun 2003 07:46:45 -0000
Received: from mailhub01.unibe.ch (130.92.9.52)
  by mail.theinternetone.net with SMTP; 22 Jun 2003 07:46:45 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailhub01.unibe.ch (Postfix) with ESMTP
	id 5A79C25BB5C; Sun, 22 Jun 2003 09:46:44 +0200 (MEST)
Received: from mailhub01.unibe.ch ([127.0.0.1])
 by localhost (mailhub01 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id 09261-01-45; Sun, 22 Jun 2003 09:46:43 +0200 (MEST)
Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4])
	by mailhub01.unibe.ch (Postfix) with ESMTP
	id 9268F25BB5B; Sun, 22 Jun 2003 09:46:43 +0200 (MEST)
Received: from iam.unibe.ch (asterix [130.92.64.4])
	by asterix.unibe.ch (8.11.6+Sun/8.11.6) with ESMTP id h5M7kdK28423;
	Sun, 22 Jun 2003 09:46:39 +0200 (MET DST)
Date: Sun, 22 Jun 2003 09:46:37 +0200
Subject: Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
To: [email protected],<[email protected]>
From: Stephane Ducasse <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Virus-checked: by University of Berne
cc: Roel Wuyts <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sun, 22 Jun 2003 07:46:46 -0000

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
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>