[squeak-dev] Re: Controller|release and View|model:controller: methods

Peter Michaux petermichaux at gmail.com
Sun Jul 8 20:35:01 UTC 2012


Hi Andreas,

Thanks for your response.

I had a feeling that Controller>>release was there to break loops to
aid reference counting garbage collectors. I've considered removing
the release method from my implementation as modern JavaScript garbage
collectors do not use reference counting (though Internet Explorer 6
did have reference counting and reference loop leaks for certain kinds
of host objects.)

I had a look at VisualWorks NC's View and Controller classes. Thanks
for the recommendation. Neither class has a release method. That is
understandable for the Controller class for the reason you mentioned.
I was surprised that setting the model of a view in their
implementation does not automatically add the view as a dependent of
the model. That is where Squeak's View>>release method is still
needed.

Peter

On Sun, Jul 8, 2012 at 12:31 PM, Andreas.Raab <andreas.raab at gmx.de> wrote:
> Hi Peter -
>
> Your observations are correct. First, IIRC the reason for
> Controller>>release is to aid the garbage collector. In some early versions
> of Smalltalk, the GCs weren't capable of detecting cycles so having the view
> point to the controller, and the controller point to the view would not
> allow any of them to be GCed, thus the need to call Controller>>release.
>
> As to View>>model:controller: and its interaction with Controller>>release,
> I think your observation and cure are both entirely correct. Since you are
> doing a reimplementation I would probably just stay away from
> Controller>>release alltogether. There should not be a need to ever call
> this, all modern systems have GCs that can cope with this problem. But if
> you want to keep release, checking for being the current controller should
> work just fine.
>
> It might also be worthwhile to check out VisualWorks NC (another heir to
> ST80 with a more modern incarnation of an MVC framework) to see if
> Controller>>release is still present there and if so, what it actually does
> :-)
>
> Cheers,
>   - Andreas
>
>
> Peter Michaux wrote
>>
>> Hi,
>>
>> My first time posting here. Hopefully I've found the right list for my
>> question.
>>
>> I've created a JavaScript MVC framework for browser applications. The
>> popular JavaScript "MVC frameworks" are not really MVC so I decided to
>> build one that actually is. (https://github.com/petermichaux/maria)
>> Although I'm not a Smalltalk programmer, I've used the Squeak View and
>> Controller classes as my primary implementation inspiration. There are
>> many places in my JavaScript code that are line-by-line ports from
>> Squeak. I've found that the few times I've experimented and deviated
>> from the principles of the Squeak View class, I've usually ended up in
>> hot water and reverted.
>>
>> I've been considering one deviation for a long time in my versions of
>> the Controller|release and View|model:controller: methods because I
>> just cannot grasp the motivation for why the Squeak code works as it
>> does. The Squeak code for Controller|release is
>>
>>     release
>>         "Breaks the cycle between the receiver and its view. It is
>>         usually not necessary to send release provided the receiver's
>>         view has been properly released independently."
>>
>>         model := nil.
>>         view ~~ nil
>>             ifTrue:
>>                 [view controller: nil.
>>                 view := nil]
>>
>> and the View|model:controller: method
>>
>>     model: aModel controller: aController
>>         "Set the receiver's model to aModel, add the receiver to
>>         aModel's list of dependents, and set the receiver's controller
>>         to aController. Subsequent changes to aModel (see Model|change)
>>         will result in View|update: messages being sent to the
>>         receiver. #NoControllerAllowed for the value of aController
>>         indicates that no default controller is available; nil for the
>>         value of aController indicates that the default controller is
>>         to be used when needed. If aController is neither
>>         #NoControllerAllowed nor nil, its view is set to the receiver
>>         and its model is set to aModel."
>>
>>         model ~~ nil & (model ~~ aModel)
>>             ifTrue: [model removeDependent: self].
>>         aModel ~~ nil & (aModel ~~ model)
>>             ifTrue: [aModel addDependent: self].
>>         model := aModel.
>>         aController ~~ nil
>>             ifTrue:
>>                 [aController view: self.
>>                 aController model: aModel].
>>         controller := aController
>>
>> By the nature of the strategy pattern, controller objects are intended
>> to be swapped in and out of view objects to modify the behavior of a
>> view. The problem that I see is that when changing the controller of a
>> view, the View|model:controller: method does not nil the view of the
>> previous controller which is being replaced. This means that several
>> controller objects can exist pointing to the same view (but the view
>> will only point to one controller.) If the release message is sent to
>> a controller that is not the view's current controller, then the view
>> still looses it current controller!
>>
>> I'm not very good at writing Smalltalk but to illustrate the point,
>> I'll give it a try...
>>
>>     alphaController := Controller new.
>>     betaController := Controller new.
>>     view := View new.
>>     view setController alphaController.
>>     view setController betaController.
>>     alphaController release.
>>
>> That last line will actually remove betaController from view which
>> seems like bad behaviour to me.
>>
>> One solution is to modify View|model:controller: to nil the previous
>> controller's view. Another solution would be to modify
>> Controller|release so that the controller checks that it is the view's
>> current controller before the line "view controller: nil." Both of
>> these could be done together.
>>
>> I'm very curious to know why the Squeak Controller|release and
>> View|model:controller: methods seem to leave this seemingly trouble
>> spot open. Thanks for any thoughts you can share on this issue.
>>
>> Peter
>>
>
>
> --
> View this message in context: http://forum.world.st/Controller-release-and-View-model-controller-methods-tp4639127p4639147.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>


More information about the Squeak-dev mailing list