Unloadable MVC changes, code reviewer needed (was: The Trunk: System-dtl.163.mcz)

> David T. Lewis uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-dtl.163.mcz
>
> ==================== Summary ====================
>
> Name: System-dtl.163
> Author: dtl
> Time: 9 November 2009, 9:55:32 am
> UUID: 625c3b61-dd78-4cd5-a60f-dc90ee753144
> Ancestors: System-dtl.162
>
> Continue factoring Project into MVCProject and MorphicProject. Add method category 'enter' for methods associated with entering one project from another, including MVC-Morphic transition. Project>>enter: revert:saveForRevert: is significantly modified. Changes are in packages System, Morphic, and ST-80.
>

> For background, these two methods handle entry into a project from another
> project, possibly involving transition from MVC or Morphic and vice versa.
> The conditional logic (#isMorphic and #isMorph) in the original method
> implementations has been replaced by methods in the MVCProject and
> MorphicProject subclasses, and these subclass methods are invoked through
> reference to self (the project being entered) or class variable CurrentProject
> (the prior project from which we are exiting).
>
> The updates in Squeak trunk are System-dtl.163, Morphic-dtl.224, and
> ST-80-dtl.64. Note that MVC is somewhat broken in trunk, so the objective
> here is to not make it any more badly broken.
>
> Thanks,
> Dave
>
> On Tue, Nov 10, 2009 at 12:58:14AM +0000, [hidden email] wrote:
>> David T. Lewis uploaded a new version of System to project The Trunk:
>> http://source.squeak.org/trunk/System-dtl.163.mcz
>>
>> ==================== Summary ====================
>>
>> Name: System-dtl.163
>> Author: dtl
>> Time: 9 November 2009, 9:55:32 am
>> UUID: 625c3b61-dd78-4cd5-a60f-dc90ee753144
>> Ancestors: System-dtl.162
>>
>> Continue factoring Project into MVCProject and MorphicProject. Add method category 'enter' for methods associated with entering one project from another, including MVC-Morphic transition. Project>>enter: revert:saveForRevert: is significantly modified. Changes are in packages System, Morphic, and ST-80.
>>
>
>

> David T. Lewis wrote:
>
> >I consider these changes somewhat risky, so I would appreciate if anyone can
> >review them and speak up if they cause problems. In particular, the methods
> >Project>>enterForEmergencyRecovery and Project>>enter:revert:saveForRevert:
> >could stand a good review.
>
> I think we should nuke enterForEmergencyRecovery and those parts in
> Project that deal with isolated changes. This is one of the projects
> that never got to a conclusion and there is no point in keeping all
> these hooks for stuff that is unused. If you want to keep the interface,
> just raise an error if you ever see a revert == true or so.

> On Mon, Nov 09, 2009 at 08:56:01PM -0800, Andreas Raab wrote:
>> David T. Lewis wrote:
>>
>>> I consider these changes somewhat risky, so I would appreciate if anyone can
>>> review them and speak up if they cause problems. In particular, the methods
>>> Project>>enterForEmergencyRecovery and Project>>enter:revert:saveForRevert:
>>> could stand a good review.
>> I think we should nuke enterForEmergencyRecovery and those parts in
>> Project that deal with isolated changes. This is one of the projects
>> that never got to a conclusion and there is no point in keeping all
>> these hooks for stuff that is unused. If you want to keep the interface,
>> just raise an error if you ever see a revert == true or so.
>
> Oh, good, that explains it. I was rather nervous about modifying a method
> when I did not even know what it was being used for.

> David T. Lewis wrote:
> >On Mon, Nov 09, 2009 at 08:56:01PM -0800, Andreas Raab wrote:
> >>
> >>I think we should nuke enterForEmergencyRecovery and those parts in
> >>Project that deal with isolated changes. This is one of the projects
> >>that never got to a conclusion and there is no point in keeping all
> >>these hooks for stuff that is unused. If you want to keep the interface,
> >>just raise an error if you ever see a revert == true or so.
> >
> >Oh, good, that explains it. I was rather nervous about modifying a method
> >when I did not even know what it was being used for.
>
> It was used in an experimental project that tried to isolate changes
> done in a project by un-applying them when you would enter another
> project. Unfortunately, the approach taken (making copies of the methods
> and applying/unapplying them when entering leaving projects) was fraught
> with perils and didn't work very well in practice. So nuke it ;-)