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
|