Squeakfoundation June 2003

squeakfoundation@lists.squeakfoundation.org

30 participants
59 discussions

Re: [Squeakfoundation]Shepherding large enhancements
by Daniel Vainsencher 26 Jun '03

26 Jun '03

diegogomezdeck(a)consultar.com wrote: > I'm going to shout also... Seems like an acepted way. Actually, I feel much better now, and am now ready for some clear discussion :-) I hope it makes you feel better too. > > He, I couldn't help myself, sorry for the shouting. ;-) But I really > > mean it. We agreed on the plan. And one of the things we wanted to do > > is to have faster release cycles than before - we are aiming for 3 > > releases per year IIRC. > > We are not talking about the plan. We're talking WHAT to do in the case > (like now) that the plan CAN'T be respected. What do you mean that the plan can't be respected? I don't see anything stopping us. > We had choosed Date and Features (an error in itself). No, we chose Date. The Plan was always meant as an attempt at a self fulfilling prophecy - by talking about something, you bring it to attention, and maybe it gets help and becomes ready for inclusion. Though this isn't explicitly said in the plan, you may note that the language around anything that requires the commitment of anyone other than Guides is very tentative. > Some of us want to > respect the date, other (including me) want to respect the Features. I don't think it is about what we want - the plan is more or less *the most we can do* about specifying features. Time we can sort of pretend to control. Any attempt to pretend to control features (people+direction), will have far less pleasant results. Specifying requirements you can't control in a plan doesn't make sense to me. > > There will ALWAYS be stuff to harvest. There will ALWAYS be cool new > > stuff to add. But we need a proper beta and gamma period. > What is more important? the "proper periods" or the results? In the long term, what determines the content of Squeak is, and always will be, the amount of effort and creativity people like you put into it. The community can help with reviews, but us Harvesters can only affect this in limited ways. What we can do, and try to *using the release cycle* is - A. Make sure that the Squeak newbies download is more or less up to date (requires somewhat frequent releases, and 3 a year doesn't seem madly over-frequent) B. Make sure that quality goes up, not down, over time, which requires some sort of quality process, including reviews, betas and gamma. Also note that the results are not on the line - NewLook is not being prevented from going in permanently - just delayed by the 3 week beta period. I hope in this time it gets reviewed and approved. > IMO, the SM1.1 is a MUST to avoid a fork in the community. I agree, in the long term. Though if you mean that SM1.1 is a MUST *in 3.6*, I disagree. I think what we'll have to do is make only one official release image, the Full image, until we have SM1.1, enabling us to manage more. Hopefully this will be early in 3.7. Yes, this will require some arguing about what packages to include in Full. Price we pay, nothing to do about it. Daniel

1 0

ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Daniel Vainsencher 25 Jun '03

25 Jun '03

[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. [... are mostly required by closures, not runtime fixes] Great. Then can you please isolate only those needed for the runtime fixes? it'll mean we have a lot less to talk about before including the runtime fixes in the image. Then we'll only need a review by someone with exceptions savvy... Daniel Anthony Hannan <ajhannan(a)yahoo.com> wrote: > > >4 Anthony runtime enhancements (split in two - fixes and closures) > > 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. > > > 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. 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. > > CompiledMethod>>headerDescription - Prints out all the components of the header > (numArgs, numLiterals, etc) in a readable format. > > 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. > > SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put: > ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:wi > 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(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

3 4

Re: [Squeakfoundation]Self-approving fixes (was Re: ContextCleanupPlus-ajh)
by Daniel Vainsencher 25 Jun '03

25 Jun '03

BTW, the recent discussions about process made me go look at the swiki at what is actually visible, and actually, if you're a new Squeaker browsing through, starting from /1, it is hard to get to the good documentation, which is a pity, because people are probably missing it all the time. I'll be adding to it and refactoring it soon. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > Daniel Vainsencher wrote: > > >I agree generally, but 25% of ones harvests seems like something that is > >too hard to keep track of. How about simply restricting it to very > >simple stuff, that is under 1k of code? > > > >This fits with a feeling I have that trivial cleanups should be easy to > >insert, because they hold little risk, and big stuff should get more > >reviews because they hold more risk. > > > > > > That sounds like a good rule. > > The 25% figure doesn't have to be a strict rule... it could be more of a > guideline. The general idea being that we want to encourage > reviewing/approving other people's submissions as much as possible. > > - Doug > > > >Doug Way <dway(a)riskmetrics.com> wrote: > > > > > >>Daniel Vainsencher wrote: > >> > >> > >> > >>>I know why isSymbol is needed, and don't personally mind your self > >>>approving it. ... > >>> > >>> > >>> > >>I've been thinking that the rigid "you can't approve your own > >>submission" rule is probably too strict. When we started up the > >>harvesting group a couple of years ago (with SqC still in charge), > >>harvesters were allowed to harvest their own submissions, as long as > >>they mostly reviewed other people's. > >> > >>What we could do is allow approving one's own submissions if they're > >>reasonably simple fixes. But we should have some rule of thumb such as: > >>no more than 25% or so of the things you harvest should be your own > >>items, because we don't want the harvesters just working on their own stuff. > >> > >>This would have the added benefit that if harvesters *really* wants to > >>get their own submissions in, they'll also review a few items from other > >>people, so that they meet the ~25% rule. > >> > >>So something like this might encourage more harvesting. It won't > >>necesssarily solve all of our current issues, but it's a start... > >> > >>- Doug > >> > >> > >> > >> > >>>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 <marcus(a)ira.uka.de> 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 marcus(a)ira.uka.de -- Squeak! http://squeak.de > >>>> > >>>>_______________________________________________ > >>>>Squeakfoundation mailing list > >>>>Squeakfoundation(a)lists.squeakfoundation.org > >>>>http://lists.squeakfoundation.org/listinfo/squeakfoundation > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>Squeakfoundation mailing list > >>>Squeakfoundation(a)lists.squeakfoundation.org > >>>http://lists.squeakfoundation.org/listinfo/squeakfoundation > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>Squeakfoundation mailing list > >>Squeakfoundation(a)lists.squeakfoundation.org > >>http://lists.squeakfoundation.org/listinfo/squeakfoundation > >> > >> > >_______________________________________________ > >Squeakfoundation mailing list > >Squeakfoundation(a)lists.squeakfoundation.org > >http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]re: TrueType font support and 3.6
by Daniel Vainsencher 25 Jun '03

25 Jun '03

I don't know about the rest of Agile Development, but XP claims that code is easy to _change_ (not fix) things *iff* up to that point, you refactored mercilessly, did the simplest things that could possibly work, and have tests to back you up. If the code in question was refactored mercilessly, we would not be having this discussion... We're not talking about potential bugs here (which additional testers might flush out, as you say), we're talking about code that hasn't been improved or pronounced ready by it's author, after recieving a first review. I don't understand what there is to discuss. Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > On Sat, Jun 21, 2003 at 06:04:03PM +0200, Daniel Vainsencher wrote: > > Hi Andreas - > > > > I'm confused too. Let's try to isolate the problem. > > > > Claim I - We have a piece of code that's candidate for inclusion. We all > > agree it has flaws as detected by even cursory inspections. > > > > Claim II - I percieve as a very obvious, general rule that at every > > stage of mixing code in with more of the real world, the price of fixing > > errors goes up, because problems are easier to solve in isolation. > > Therefore, make it work, make it right, then deploy wider. > > > > Problem is: Claim II is wrong. And obvioulsy so: Adding a big > changeset to Squeak takes a long time: It needs to be reviewed, > and discussed (image or package?). Most of the time those things > are pretty complicated, just because they tuch a lot of stuff > where not many reviewsers are real experts. So adding big things > takes time. > > On the other hand: small, isolated refactorings, that fix a little > thingy at one place can be harvested *very* fast: lots of people > can review a simple refactoring (e.g. removing a direct reference > to a class) without understanding the whole thing that was once that > big changeset. > > Another thing: Adding even not-perfectly working stuff can be good, because > it gets tested by lots of people, and most squeakers who > follow the update stream actively fix bugs they encounter. They > do this for the stuff in the update stream, not for those big changesets > that are in the review process. > > So my claim (which is not new btw, it's the basis of the whole "Agile > Development" Hype) is that it's less expensive to fix things later > than most people would intuitivly guess. > > Marcus > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

7 15

Self-approving fixes (was Re: ContextCleanupPlus-ajh)
by Daniel Vainsencher 25 Jun '03

25 Jun '03

I agree generally, but 25% of ones harvests seems like something that is too hard to keep track of. How about simply restricting it to very simple stuff, that is under 1k of code? This fits with a feeling I have that trivial cleanups should be easy to insert, because they hold little risk, and big stuff should get more reviews because they hold more risk. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > Daniel Vainsencher wrote: > > >I know why isSymbol is needed, and don't personally mind your self > >approving it. ... > > > > I've been thinking that the rigid "you can't approve your own > submission" rule is probably too strict. When we started up the > harvesting group a couple of years ago (with SqC still in charge), > harvesters were allowed to harvest their own submissions, as long as > they mostly reviewed other people's. > > What we could do is allow approving one's own submissions if they're > reasonably simple fixes. But we should have some rule of thumb such as: > no more than 25% or so of the things you harvest should be your own > items, because we don't want the harvesters just working on their own stuff. > > This would have the added benefit that if harvesters *really* wants to > get their own submissions in, they'll also review a few items from other > people, so that they meet the ~25% rule. > > So something like this might encourage more harvesting. It won't > necesssarily solve all of our current issues, but it's a start... > > - Doug > > > >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 <marcus(a)ira.uka.de> 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 marcus(a)ira.uka.de -- Squeak! http://squeak.de > >> > >>_______________________________________________ > >>Squeakfoundation mailing list > >>Squeakfoundation(a)lists.squeakfoundation.org > >>http://lists.squeakfoundation.org/listinfo/squeakfoundation > >> > >> > >_______________________________________________ > >Squeakfoundation mailing list > >Squeakfoundation(a)lists.squeakfoundation.org > >http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Daniel Vainsencher 24 Jun '03

24 Jun '03

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 <marcus(a)ira.uka.de> 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 marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Anthony Hannan 24 Jun '03

24 Jun '03

> >4 Anthony runtime enhancements (split in two - fixes and closures) 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. > 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. 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. CompiledMethod>>headerDescription - Prints out all the components of the header (numArgs, numLiterals, etc) in a readable format. 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. SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put: ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:wi 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

7 10

A Steward volunteering! Re: We need a Maintainer for Scamper...
by Daniel Vainsencher 23 Jun '03

23 Jun '03

I think it would be cool. May the force be with you ;-) Daniel goran.krampe(a)bluefish.se wrote: > Hi Serge, fellow Guides and all! > > Serge Stinckwich <Serge.Stinckwich(a)info.unicaen.fr> wrote: > > Le sam 21/06/2003 à 13:59, Marcus Denker a écrit : > > > Hi, > > > > > > Anyone interested in maintaining Scamper? SqueakMap says: > > > > > > Scamper > > > Summary: Installs the Scamper web browser application > > > Author: Lex Spoon > > > Maintainer: Nobody yet > > > Registrant: Adam Spitz > > > > > > At least we need someone who collects ENH/FIXes from the list, send > > > [closed] message and, from time to time, make a new release... > > > > > > Marcus > > > > I would like to help Squeak dev, but don't want to be part of a core > > part. So if no one make an objection, i could register to maintain this > > package. > > Goodie! > > To keep things simple then - I am moving this message over to the > SqF-list and keeping you in the To: field if you are not on that list. > > Fellow Guides: Can we agree to place Serge as a Steward for Scamper? :-) > > When (I assume this) the other Guides approve you, you can email Adam > Spitz to get the password for the registration and then edit it. You > could fix the summary while you are at it btw (that it "installs" is not > really interesting). > > Then I will sign you up on this page: > http://minnow.cc.gatech.edu/squeak/3088 > > Read a bit more btw on http://minnow.cc.gatech.edu/squeak/3091 > > regards, Göran > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 2

Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Daniel Vainsencher 23 Jun '03

23 Jun '03

I tried, got no reply. OTOH, I've been RBLed before, so I'm not reading too much into it. If they agree to relicense under BSD/MIT/SqueakL license, that would be very cool. Daniel Joshua 'Schwa' Gargus <schwa(a)cc.gatech.edu> wrote: > Has anyone contacted the SmaCC authors and asked? Maybe we can get > Alan to ask; it would be tough for a Smalltalker to say no ;-) >

1 0

Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
by Daniel Vainsencher 23 Jun '03

23 Jun '03

[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(a)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(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation June 2003