Old call for volunteers still up to date

Marcel Weiher marcel at metaobject.com
Tue Apr 11 20:35:13 UTC 2000


Hmm, nothing in the message says exactly what the problem is, except  
that it has to do with improving #printOn: for Array and Symbol.

What exactly are the problems, what would be a good fix?

Anyway, one suggestion I have is that EncodingFilters were created  
exactly for encoding messages like #printOn:, and might be useful for  
the proble at hand, whatever it turns out to be exactly... :-)

One problem that I've encounted (which may or may not be related) is  
that things like #printOn: tend to have uses that have subtly  
different requirements.  These subtle differences aren't captured  
because doing so would be very expensive, a new message similar to  
#printOn: would have to be defined and implemented.  Reusing  
#printOn: implementations is generally difficult because they have  
the selector #printOn: hard-coded in the method for encoding  
sub-structures.

Anyway, I would volunteer to do a massive refactoring of  
encoding-objects and protocol in terms of EncodingFilters.  Of  
course, I would probably need some specification / unit tests for the  
current functionality in order not to make a complete hash of it.

Marcel

> From: Stephane Ducasse <ducasse at iam.unibe.ch>
> Hi
>
> long time ago
> (january 11) Dan sent the following call for volunteers.
>
> I would like to know if somethign happened.
>
> Folks -
>
> This is another topic on which we have been around at least once  
before.  The
> last time we discussed it, I channelled it into a project where I  
suggested a
> number of ANSI (or other de-facto) compatibility issues might be  
addressed
> together.  This was a mistake.  Like a political bills with too  
many barnacles,
> the effort pretty much died there.
>
> The issue is of low priority to SqC, and that is why we haven't  
done more
> (though Vassili Bykov did notice that I recently implemented  
#'string for
> symbol'). That was easy because I knew it didn't conflict with  
anything else in
> Squeak.
>
> The proposals before us are not so simple, because code such as
>         strm nextPutAll: 'named: '; print name; cr
> will fail if Symbols print differently.
>
> However, it is clear to me that this would be a Good Thing, and  
this is the
> perfect time to make such a change.  2.7 is out and we have plenty  
of time to
> shake down this kind of change in 2.8alpha.
>
> Here is a proposal for getting it done:
>
> 1)  Some brave soul or (as we used to say in the 60's) affinity  
group steps
> forward to draft a spec for better Symbol and Array printOn: (and  
whatever
> not-too-vast set of other things that should accompany them).
>
> 2)  We (all Squeakies) bless this, and someone implements it.
>
> 3)  It then gets circulated for review and test as a fileIn (not  
an update).
>
> 4)  We beat on it for a week, and report/fix bugs as usual.
>
> 5)  As soon as it looks reasonable, I'll put it out as an update  
for 2.8alpha,
> where it will get lots more testing before 2.8 is done.
>
> Does this sound like an effective approach?
>
> Do we have some volunteers?
>
>         - Dan
> Stephane DUCASSE (ducasse at iam.unibe.ch)
> http://www.iam.unibe.ch/~ducasse/
> "if you knew today was your last day on earth, what would you do
> different? ... especially if, by doing something different, today  
> might not be your last day on earth" Calvin&Hobbes
>
> University of Bern, Institut fuer informatik and Mathematik
> IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.
>
>
>
>





More information about the Squeak-dev mailing list