KCP feedback (ii)

Stephane Ducasse ducasse at iam.unibe.ch
Mon May 5 06:52:29 UTC 2003


>

Hi daniel
I have to check but normally this will be fixed when tge 
compactClassesArray
will be moved from SystemDictionary. So now this is not a bug.

> 0011:
> Behavior>>becomeCompact has the line (also a similar method)
> 	cct _ self environment compactClassesArray.
> Since you're taking SystemDictionary apart (woohoo!) be careful to then
> also fix all these references you change to self environment. I'm not
> sure this isn't making things more difficult for you, but anyway, you
> can later look for environment senders, I guess.

Exactly this is the idea the system ***Have*** to continue while we are 
working on it.
so we do all kind of really small changes even when creating the 
changesets to ensure that
we can still use the environment while cleaning.

>
> About SystemNavigation - it has a nice comment that does answer some of
> the questions I had, but can you say something about how it's supposed
> to fit into everything? for example, why all the similar 
> implementations
> of self systemNavigator and not one implementation in Object (wait!
> don't shoot!) in a class extension? it's not very clear in what case
> you'd need state for this bunch of utility methods, so what examples 
> did
> you have in mind when you made them instance side?

Because right now we do not have a good way of dealing with class 
extensions. As soon as
we will get a real package notion this will be easy to fix. But may be 
we should do that now.
I did not discuss this point with other.

> With all the deprecation going on, is there a test that finds all
> deprecated methods, finds all their senders, and makes sure it's 0, or
> that the senders are to self environment or self navigator? seems to me
> safer than all the "this should be deprecated" tests, because one of
> these tests might be missing.

I'm not really happy with the tests we have right now. I would like to 
have something
that check that layers are respected and that core only refer to 
authorized classes.
So the test you propose is good.

>  It seems a bit more complicated than this,
> because some are not renamed, just moved, but I think some partial
> sanity checks of this type might be good.

oh **YES**

>
> 13, 14, 16, 18, 19, 21: approved. Thank you for moving to the
> self-sufficient-changeset style (where deprecation of a method and it's
> redefinition in SystemNavigation are in the same changeset). It's much
> easier to check.

This is also important because this way you get notified with the right 
information
when you will run 3.4 code on 3.6. that's why the deprecated methods 
should be included.
I imagine also that we can query them to produce a log of changes, 
which would be good anyway for documenting simply all the changes made 
in Squeak.

> 22, 24, 26, 28, 30, 32, 34, 38, 40, 41, 43, 45, 46, 48 50 52, 55 and 57
> approved.
>
> Daniel
>
>
Prof. Dr. Stephane DUCASSE  	[ | ]
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

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Online Free Books at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html



More information about the Squeak-dev mailing list