Making Seaside work in Pharo 4
In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus was removed. What is the correct way to replace it? WABrowser uses a nautilus browser to show a web-based browser. (build 609, Seaside #'release3.1' pharo4, from ci) WABrowserTest>>testContentsNotifying | model | model := WABrowser browserClass new. model systemCategoryListIndex: (model systemCategoryList indexOf: 'Seaside-Tests-Pharo-Development'). model classListIndex: (model classList indexOf: #WABrowserTest). model messageCategoryListIndex: (model messageCategoryList indexOf: #'-- all --'). [ self assert: (model contents: 'sampleMethod ^ 1 + 1' notifying: self). self assert: message isNil ] ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ] Stephan
strange that it was removed. Le 24/3/15 09:21, Stephan Eggermont a écrit :
In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus was removed. What is the correct way to replace it? WABrowser uses a nautilus browser to show a web-based browser. (build 609, Seaside #'release3.1' pharo4, from ci)
WABrowserTest>>testContentsNotifying | model | model := WABrowser browserClass new. model systemCategoryListIndex: (model systemCategoryList indexOf: 'Seaside-Tests-Pharo-Development'). model classListIndex: (model classList indexOf: #WABrowserTest). model messageCategoryListIndex: (model messageCategoryList indexOf: #'-- all --'). [ self assert: (model contents: 'sampleMethod ^ 1 + 1' notifying: self). self assert: message isNil ] ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ]
Stephan
It was in the âprivateâ category and as such removed when there where no senders anymore after a cleanup.
On 25 Mar 2015, at 18:55, stepharo <stepharo@free.fr> wrote:
strange that it was removed.
Le 24/3/15 09:21, Stephan Eggermont a écrit :
In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus was removed. What is the correct way to replace it? WABrowser uses a nautilus browser to show a web-based browser. (build 609, Seaside #'release3.1' pharo4, from ci)
WABrowserTest>>testContentsNotifying | model | model := WABrowser browserClass new. model systemCategoryListIndex: (model systemCategoryList indexOf: 'Seaside-Tests-Pharo-Development'). model classListIndex: (model classList indexOf: #WABrowserTest). model messageCategoryListIndex: (model messageCategoryList indexOf: #'-- all --'). [ self assert: (model contents: 'sampleMethod ^ 1 + 1' notifying: self). self assert: message isNil ] ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ]
Stephan
Marcus Denker-4 wrote
It was in the âprivateâ category and as such removed when there where no senders anymore after a cleanup.
Ahh, I like that practice! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Making-Seaside-work-in-Pharo-4-tp4814663p4815270.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Marcus Denker-4 wrote
It was in the âprivateâ category and as such removed when there where no senders anymore after a cleanup.
Ahh, I like that practice!
I was thinking that the deprecation pragma should be used (to warn users) and a lint rule added (to help users preparing migration) and then the method can be safely removed in the next version. I know that it is fastidious to do so perhaps it is an idea to improve tools on that front. Luc
----- Cheers, Sean -- View this message in context: http://forum.world.st/Making-Seaside-work-in-Pharo-4-tp4814663p4815270.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 26 Mar 2015, at 15:12, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>: Marcus Denker-4 wrote
It was in the âprivateâ category and as such removed when there where no senders anymore after a cleanup.
Ahh, I like that practice!
I was thinking that the deprecation pragma should be used (to warn users) and a lint rule added (to help users preparing migration) and then the method can be safely removed in the next version. I know that it is fastidious to do so perhaps it is an idea to improve tools on that front.
The problem is that it is hard to do when the code changes a lot. e.g. maybe the method even makes no sense conceptually anymore? Private methods are about private implementation detailsâ¦. keeping a system working with deprecation for private methods I think is near impossible. Marcus
2015-03-26 15:16 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 26 Mar 2015, at 15:12, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
Marcus Denker-4 wrote
It was in the âprivateâ category and as such removed when there where no senders anymore after a cleanup.
Ahh, I like that practice!
I was thinking that the deprecation pragma should be used (to warn users) and a lint rule added (to help users preparing migration) and then the method can be safely removed in the next version. I know that it is fastidious to do so perhaps it is an idea to improve tools on that front.
The problem is that it is hard to do when the code changes a lot. e.g. maybe the method even makes no sense conceptually anymore? Private methods are about private implementation detailsâ¦. keeping a system working with deprecation for private methods I think is near impossible.
ah now I understand. you mean that the method was private *initially*. ok, I wrongly understood that you moved the method in the "private" protocol to signal that it will be removed in the next release. So ok you are right, private methods can change and external should not rely on it. Luc
Marcus
participants (5)
-
Luc Fabresse -
Marcus Denker -
Sean P. DeNigris -
Stephan Eggermont -
stepharo