About KCP and automatic initialize

Andreas Raab andreas.raab at gmx.de
Mon Sep 15 23:24:21 UTC 2003


Hi Colin,

> Have you got some way to reduce the risk that I don't know about?
> Tell me about it.

One way to go about this problem is to provide tests which can detect such
incompatible patterns. I'm attaching a NewInitializeTest which will match
all implementations of #new against one of the deemed "obsolete"
implementations. This test can be extended to capture other situations too,
and similar tests could be written for and run in other dialects.

While this does not rule out _all_ of the situations in which the
compatibility issue occurs, having a (set of) tests can certainly greatly
simplify things. But then, if you write a package and take tests seriously
you should certainly ensure that a newly created and initialized object is
set up correctly so I would guess that well-written tests would point this
out immediately.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Colin Putney
> Sent: Tuesday, September 16, 2003 12:48 AM
> To: The general-purpose Squeak developers list
> Subject: Re: About KCP and automatic initialize
> 
> 
> 
> On Monday, September 15, 2003, at 12:33 PM, ducasse wrote:
> 
> > I should say that I admire your dramatic way of presenting the 
> > situation.
> 
> Ouch. It's certainly possible that I've overestimated the 
> difficulty of 
> making this change.
> 
> What worries me is that it would change one of the most fundamental 
> things in the system: the creation of objects. Perhaps "chaos" is too 
> strong a word to describe the bugs that will result. But I have no 
> doubt there will be a number of them, both during the transition and 
> afterwards.
> 
> And actually, afterwards is probably an even bigger issue. 
> This change 
> would introduce an incompatibility with other Smalltalks at a pretty 
> fundamental level. It would be that much more difficult to port code 
> between Squeak and other Smalltalks because you have to examine the 
> nuances of how you create objects. This is a much higher barrier to 
> interoperability with other Smalltalks than, say, a slightly 
> different 
> socket API, or a different GUI system.
> 
> Now don't get me wrong, I'm all for advancing the state of 
> the art. But 
> I don't see this as a progress vs. status quo issue. What 
> we're talking 
> about here is a refactoring. There's a pattern that's implemented in 
> hundreds of places in the system, and we can reduce that 
> duplication by 
> applying "pull up method."
> 
> Whether or not we should is a question of risk vs benefit. Will the 
> increase in clarity and maintainability of the code be worth the risk 
> that bugs will be introduced because of the break in 
> compatibility? My 
> gut feeling is that it won't. Am I underestimating the benefits? Have 
> you got some way to reduce the risk that I don't know about? Tell me 
> about it.
> 
> Colin
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewInitializeTest.st
Type: application/octet-stream
Size: 4398 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030916/0701d2f8/NewInitializeTest.obj


More information about the Squeak-dev mailing list