[Pharo-project] MVC removing step2: your point of view
Hi all, I'm cleaning some methods which contain 'AsMorph'. for example, Browser>>openAsMorphMessageEditing: is send only in Browser>>openMessageEditString: which only returns openAsMorphMessageEditing: result. so, I copy code from Browser>>openAsMorphMessageEditing: to Browser>>openMessageEditString: and remove Browser>>openAsMorphMessageEditing:. I guess this is ok. But now I'm continuing by chasing all methods with 'InMorphic' in their name. As an example, there is Morph>>embeddedInMorphicWindowLabeled:. the question is, do I make the asumption that morphic is the only way or the default (then Morph>>embeddedInMorphicWindowLabeled: can be renamed as Morph>>embeddedInWindowLabeled:) or do I let it as is ? the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (->inspect:), inspectInMorphic (->removed because no sender), thanks alain
Hi, If we take the separation of concens principle, GUI code should be totally separated from the model one. GUI can have a knowledge of the model, but the model should not care about the view. So, we should have a BrowserModel and a MorphicBrowser. Every new GUI system will require implementing its own view... And views of the same model will all be polymorphic and accept an open message. Now, this separation is not done in the plain Browser. So, the underlying question is that should we maintain this bad design. My position is that more cleanup should be done before introducing a new GUI system. So, I suggest to rename the method "open". Noury On 5 juin 08, at 13:52, Alain Plantec wrote:
Hi all, I'm cleaning some methods which contain 'AsMorph'. for example, Browser>>openAsMorphMessageEditing: is send only in Browser>>openMessageEditString: which only returns openAsMorphMessageEditing: result. so, I copy code from Browser>>openAsMorphMessageEditing: to Browser>>openMessageEditString: and remove Browser>>openAsMorphMessageEditing:. I guess this is ok. But now I'm continuing by chasing all methods with 'InMorphic' in their name. As an example, there is Morph>>embeddedInMorphicWindowLabeled:. the question is, do I make the asumption that morphic is the only way or the default (then Morph>>embeddedInMorphicWindowLabeled: can be renamed as Morph>>embeddedInWindowLabeled:) or do I let it as is ?
the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (-
inspect:), inspectInMorphic (->removed because no sender),
thanks alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------
alain you should pay attention that you shoudl deprecate the method. People should be able to load their code in pharo On Jun 5, 2008, at 1:52 PM, Alain Plantec wrote:
Hi all, I'm cleaning some methods which contain 'AsMorph'. for example, Browser>>openAsMorphMessageEditing: is send only in Browser>>openMessageEditString: which only returns openAsMorphMessageEditing: result. so, I copy code from Browser>>openAsMorphMessageEditing: to Browser>>openMessageEditString: and remove Browser>>openAsMorphMessageEditing:. I guess this is ok. But now I'm continuing by chasing all methods with 'InMorphic' in their name. As an example, there is Morph>>embeddedInMorphicWindowLabeled:. the question is, do I make the asumption that morphic is the only way or the default (then Morph>>embeddedInMorphicWindowLabeled: can be renamed as Morph>>embeddedInWindowLabeled:) or do I let it as is ?
the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (-
inspect:), inspectInMorphic (->removed because no sender),
thanks
for now I'm not sure that I would focus on that. I would clean really the ugly part and etoy. stef
alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thursday 5 June 2008 16:08:34 Stéphane Ducasse wrote:
alain
you should pay attention that you shoudl deprecate the method. ok, I'm aware of this People should be able to load their code in pharo well but I don't know how to really remove mvc and keep backward compatibility even some method are kept as deprecated.
...
the same would be applied to openInMorphic (->open), inspectModelInMorphic (->inspectModel), inspectInMorphic: (-
inspect:), inspectInMorphic (->removed because no sender),
thanks
for now I'm not sure that I would focus on that. I would clean really the ugly part and etoy. ok, no problem, I can help gary on etoy now alain
stef
alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Alain Plantec -
Noury Bouraqadi -
Stéphane Ducasse