Hi, In other smalltalks, which had the capability of marking a method with more than one category, I could make a method public/private AND it's functional category (accessor, printing, etc) I did this to explicitly show the user which methods I expect to be sent to the object and which ones I don't. It didn't seem to me I can assign more than one category in Pharo, so my question is: How can I deal with this problem? Which is "the Pharo way" to accomplish this?
Sergio, a few times I also wanted that. And the only way of doing it I found was by doing defining protocols like 'public' , 'public - subcategoryX', 'public - subcategoryY' , etc... not sure powerful but simple. Cheers, On Mon, Apr 27, 2015 at 7:53 PM, Sergio Fedi <sergio.fedi@gmail.com> wrote:
Hi,
In other smalltalks, which had the capability of marking a method with more than one category, I could make a method public/private AND it's functional category (accessor, printing, etc)
I did this to explicitly show the user which methods I expect to be sent to the object and which ones I don't.
It didn't seem to me I can assign more than one category in Pharo, so my question is:
How can I deal with this problem? Which is "the Pharo way" to accomplish this?
-- Mariano http://marianopeck.wordpress.com
The only other way I can think of doing this is via the virtual categories (which Pharo seems to have) and make them look for "Public" at the beggining of the first comment. Not fancy, but practical. â
I already do that. (and I also make sure my tests have 100% coverage over the Public protocol) But to know that you have to memorize the methods that are in the test cases. Besides, I may want to test private methods too. â
On 28/04/15 01:44, Sergio Fedi wrote:
I already do that. (and I also make sure my tests have 100% coverage over the Public protocol)
But to know that you have to memorize the methods that are in the test cases. Besides, I may want to test private methods too.
The categorization of methods is a weak way of showing the user, as it is decoupled from the actual code, i.e. when I change the behaviour, there is no automatic update of the category. With Glamour/GTInspector extensions you could create an API browser from e.g. marking API methods with a pragma or using a TestCase subclass APITest Stephan
Stephan, isn't that a weak argument? If I change the bhavior of a method and forget to rename it to something intention revealing, there also is no guarantuee that the name tells a developer anything about it... Joachim
Stephan Eggermont <stephan@stack.nl> hat am 28. April 2015 um 12:17 geschrieben:
On 28/04/15 01:44, Sergio Fedi wrote:
I already do that. (and I also make sure my tests have 100% coverage over the Public protocol)
But to know that you have to memorize the methods that are in the test cases. Besides, I may want to test private methods too.
The categorization of methods is a weak way of showing the user, as it is decoupled from the actual code, i.e. when I change the behaviour, there is no automatic update of the category.
With Glamour/GTInspector extensions you could create an API browser from e.g. marking API methods with a pragma or using a TestCase subclass APITest
Stephan
participants (4)
-
Joachim Tuchel -
Mariano Martinez Peck -
Sergio Fedi -
Stephan Eggermont