About KCP and automatic initialize

Colin Putney cputney at wiresong.ca
Tue Sep 16 19:48:23 UTC 2003


On Tuesday, September 16, 2003, at 02:19  AM, Daniel Vainsencher wrote:

> 1. Stef has done it and used the image, therefore, it doesn't break
> everything.

Well, that's a good start, but I'm more worried about external packages 
than the image.

> 2. We have a partial test suite we can run. It will detect some bugs,
> and where it doesn't, we'll have a good motivation to add tests.

Now *this* definitely has a lot of potential. I wonder if it would be 
feasibly to develop a test suite for porting from other Smalltalks. Or 
maybe some SLint rules.

> 3. As far as short term instability is concerned - we are in alpha...

Agreed.

> 4. As far as incompatibility with other Smalltalks is concerned, this
> will cause no problems when porting DialectX-> Squeak, and simple
> problems when porting Squeak -> DialectX. Problems which are solved by
> adding "new super basicNew initialize" (or whatever that silly idiom
> really is) to each imported class. Doesn't seem like really bad risk to
> me.

I might agree that there would be *fewer* problems with 
DialectX->Squeak, but not none. The common case would be that code 
developed in DialectX would have double initialization when run on 
Squeak and Squeak code would have no initialization when run on 
DialectX. Double initialization might be ok sometimes, but I can 
certainly think of cases where it would cause problems.

There have been a few other replies to my benefit vs risk post arguing 
that the risk is lower than I made it out to be. I don't think this is 
the case. The fact that most of the bugs will be trivial doesn't change 
the fact that there will be a lot of them or make them less annoying. 
Still, it's clear than many expert opinions do find the benefit to be 
worth the risk, so it may be that I've underestimated the benefit end 
of the balance.

Anyway, consider me convinced. Let's do it. I'll just say "I told you 
so" now and get it out of the way.

Colin



More information about the Squeak-dev mailing list