access modifier migration - how to proceed?

[Philipp Tessenow]

Hi All,

Now that we have image-side access modifier support for everything under the sun, I have created an ugly script, which can
trick Memory Hole into saving the source code with access modifiers of my choosing (I can publish that script in some way if you like).

I've done it this way, because I want to re-use the Newspeak parser (which is in the image), but I cannot directly change
access modifiers in the live image*.

Now that I can migrate access modifiers of the Newspeak source, I am not sure on how to proceed. This are the steps that
I plan to do:

1. change every access modifier to private
   
2. make changes to the VM to output warnings on every access violation
3. run the image (run tests, browse code, ...) to generate lots of warnings
4. parse the warnings and upgrade access modifiers where violations occur
5. continue with 3. until there are no more access violations
6. change the VM to give a MNU instead of a warning for access violations
   

How should I contribute my changes to the Newspeak sources?

a) Shall I make a pull request for step 1 and later add pull requests containing the modifier upgrades (step 5)?
b) Shall I make a single big pull request with all changes after step 5?

The problem is that I expect time to pass between step 1 and step 5. For variant a) every change to the Newspeak source
needs to keep in mind that access modifiers must be private. For b) I have to restart the migration process for every
change in the Newspeak repositories (so that I don't miss them, and to avoid merge conflicts).

a) might be cumbersome for everybody (but me); b) is cumbersome for me :)
Which way do you prefer or do you have other ideas on how to proceed?

--
  Philipp


*) I cannot directly change access modifiers in the live image, because some classes are more special than others and
cannot be recompiled. For example, if I change an access modifier (or add a slot) in the Kernel class, my images stops
working, because it does not initialize the Kernel class slots (e.g. the Dictionary slot is nil).

[Gilad Bracha]

Hi Philipp,

On Wednesday, February 5, 2014 2:09:42 AM UTC-8, Philipp Tessenow wrote:

Hi All,

Now that we have image-side access modifier support for everything under the sun, I have created an ugly script, which can
trick Memory Hole into saving the source code with access modifiers of my choosing (I can publish that script in some way if you like).

I've done it this way, because I want to re-use the Newspeak parser (which is in the image), but I cannot directly change
access modifiers in the live image*.

That sounds wrong. 

 

Now that I can migrate access modifiers of the Newspeak source, I am not sure on how to proceed. This are the steps that
I plan to do:

1. change every access modifier to private
   

Ideally one would avoid reducing access on anything that has its access set explicitly. Since that may be expensive to do dynamically, I'd  try to avoid tampering with anything declared public, since that had to be set explicitly.

Protected members are more complex since one has to look at the source to decide. Once could do this via a script that compares the old source base to the one with revised access. Anything explicitly marked protected that had been downgraded could then be be fixed.

2. make changes to the VM to output warnings on every access violation
3. run the image (run tests, browse code, ...) to generate lots of warnings
4. parse the warnings and upgrade access modifiers where violations occur
5. continue with 3. until there are no more access violations
6. change the VM to give a MNU instead of a warning for access violations
   

How should I contribute my changes to the Newspeak sources?

a) Shall I make a pull request for step 1 and later add pull requests containing the modifier upgrades (step 5)?
b) Shall I make a single big pull request with all changes after step 5?

The problem is that I expect time to pass between step 1 and step 5. For variant a) every change to the Newspeak source
needs to keep in mind that access modifiers must be private. For b) I have to restart the migration process for every
change in the Newspeak repositories (so that I don't miss them, and to avoid merge conflicts).

a) might be cumbersome for everybody (but me); b) is cumbersome for me :)

As you'd expect, we'd rather burden you :-)

[Ryan Macnak]

On Wed, Feb 5, 2014 at 2:09 AM, Philipp Tessenow <phi...@tessenow.org> wrote:

I plan to do:

1. change every access modifier to private
   
2. make changes to the VM to output warnings on every access violation
3. run the image (run tests, browse code, ...) to generate lots of warnings
4. parse the warnings and upgrade access modifiers where violations occur
5. continue with 3. until there are no more access violations
6. change the VM to give a MNU instead of a warning for access violations 

I think it should be a goal for the upgrade path to be automatic, so we can run it again later as we exercise new code paths or other code bases not in the public repository.

 

*) I cannot directly change access modifiers in the live image, because some classes are more special than others and
cannot be recompiled. For example, if I change an access modifier (or add a slot) in the Kernel class, my images stops
working, because it does not initialize the Kernel class slots (e.g. the Dictionary slot is nil).

This works for me. The only restriction is the order of the slots in subclasses of Behavior or Mixin must not change.