When you try to name a methodCategoryPrefix with a capital letter, like ^ '*test Protocol', this extension protocol don't appear in *Extensions in the monticello snapshot browser. But it's work when the capital letter is the first letter like ^ '*Refactory'.
Samir
Samir Saidani wrote:
When you try to name a methodCategoryPrefix with a capital letter, like ^ '*test Protocol', this extension protocol don't appear in *Extensions in the monticello snapshot browser. But it's work when the capital letter is the first letter like ^ '*Refactory'.
Samir
Works for me...
I added a package called 'test protocol' and then a method #foo on a random class in the category '*test Protocol' and it shows up in the package browser under extensions.
What were you naming your package?
Julian
Weird !
Take a vanilla Squeak 3.6 #5424, load a SMSqueakMap2 (Squeak asks for it), then Monticello Package v94,
In category Test, add MyTestClass derived from PackageInfo, add a methodCategoryPrefix ^'*test' then add where you want this protocol.
Add the Test Package in Monticello, Browse it : all it's ok. Rename it '*test protocol' with appropriate changes, it works. '*Test protocol' don't work. *Testprotocol don't work. *testprotocol work. *testProtocol don't work *test Protocol don't work.
Could you try ?
Julian Fitzell julian@beta4.com writes:
Samir Saidani wrote:
When you try to name a methodCategoryPrefix with a capital letter, like ^ '*test Protocol', this extension protocol don't appear in *Extensions in the monticello snapshot browser. But it's work when the capital letter is the first letter like ^ '*Refactory'. Samir
Works for me...
I added a package called 'test protocol' and then a method #foo on a random class in the category '*test Protocol' and it shows up in the package browser under extensions.
What were you naming your package?
Julian
Samir Saidani wrote:
Weird !
Take a vanilla Squeak 3.6 #5424, load a SMSqueakMap2 (Squeak asks for it), then Monticello Package v94,
In category Test, add MyTestClass derived from PackageInfo, add a methodCategoryPrefix ^'*test' then add where you want this protocol.
Add the Test Package in Monticello, Browse it : all it's ok. Rename it '*test protocol' with appropriate changes, it works. '*Test protocol' don't work. *Testprotocol don't work. *testprotocol work. *testProtocol don't work *test Protocol don't work.
Could you try ?
If you package is called "Test" then I wouldn't expect it to pick up any of those (the fact that it picks up '*test protocol' sounds like a bug). If you want it to be part of the Test package, you should name the method category '*test' or '*test-protocol'...
Or am I misunderstanding what you're trying to do?
Julian
Julian Fitzell julian@beta4.com writes:
Samir Saidani wrote:
Weird ! Take a vanilla Squeak 3.6 #5424, load a SMSqueakMap2 (Squeak asks for it), then Monticello Package v94, In category Test, add MyTestClass derived from PackageInfo, add a methodCategoryPrefix ^'*test' then add where you want this protocol. Add the Test Package in Monticello, Browse it : all it's ok. Rename it '*test protocol' with appropriate changes, it works. '*Test protocol' don't work. *Testprotocol don't work. *testprotocol work. *testProtocol don't work *test Protocol don't work. Could you try ?
If you package is called "Test" then I wouldn't expect it to pick up any of those (the fact that it picks up '*test protocol' sounds like a bug). If you want it to be part of the Test package, you should name the method category '*test' or '*test-protocol'...
Or am I misunderstanding what you're trying to do?
In my mind, as a monticello user, the methodCategoryPrefix I choose is totally disconnected from the package name since nothing in monticello doc says the opposite : if I have a package named MyTestInfo, I can name the method category '*myTest' which seems to be quite reasonable or whatever like '*my super Test', maybe more fantaisist, but both don't work anyway. I really don't understand why there is a constraint on the name of methodCategoryPrefix, but if there is one, could you clearly state what is this constraint in a readmeText of monticello package ? I spend a lot of time to figure out what is the naming policy !
Thanks a lot for your support, I really like this tool !
Samir
On Jan 30, 2004, at 10:55 AM, Samir Saidani wrote:
In my mind, as a monticello user, the methodCategoryPrefix I choose is totally disconnected from the package name since nothing in monticello doc says the opposite : if I have a package named MyTestInfo, I can name the method category '*myTest' which seems to be quite reasonable or whatever like '*my super Test', maybe more fantaisist, but both don't work anyway. I really don't understand why there is a constraint on the name of methodCategoryPrefix, but if there is one, could you clearly state what is this constraint in a readmeText of monticello package ? I spend a lot of time to figure out what is the naming policy !
There isn't a constraint on the #methodCategoryPrefix (Julian was describing the default rules, I'm not sure he picked up that you were subclassing PackageInfo). However, there are still rules about how the prefix is applied - the only categories that should match are those with names identical to the prefix, or those with the prefix, then '-', then something else. That is, if you are going to put additional information after the prefix it has to be separated from the prefix with a hyphen, not a space. This is to reduce conflicts if two packages have overlapping prefixes.
Does that help?
Avi
Avi Bryant avi@beta4.com writes:
There isn't a constraint on the #methodCategoryPrefix (Julian was describing the default rules, I'm not sure he picked up that you were subclassing PackageInfo). However, there are still rules about how the prefix is applied - the only categories that should match are those with names identical to the prefix, or those with the prefix, then '-', then something else. That is, if you are going to put additional information after the prefix it has to be separated from the prefix with a hyphen, not a space. This is to reduce conflicts if two packages have overlapping prefixes.
Does that help?
It was the behavior I expected, but when there is a space or a capital letter in the prefix, it doesn't work as expected.
Samir
On Jan 30, 2004, at 11:48 AM, Samir Saidani wrote:
It was the behavior I expected, but when there is a space or a capital letter in the prefix, it doesn't work as expected.
It makes sense that there would be problems with a capital letter - the way the code is currently written, the prefix is expected to be all lowercase (and categories are all lowercased when compared to it, so it's not case sensitive). I actually wasn't expecting people to override that particular method, it should be factored a little differently for that to work better. I don't understand why there would be problems with having a space in the prefix.
Avi Bryant avi@beta4.com writes:
It makes sense that there would be problems with a capital letter - the way the code is currently written, the prefix is expected to be all lowercase (and categories are all lowercased when compared to it, so it's not case sensitive). I actually wasn't expecting people to override that particular method, it should be factored a little differently for that to work better. I don't understand why there would be problems with having a space in the prefix.
Sorry, you're right, there is no problem with space in prefix, I was confused by the example '*test Protocol', because there is a space, but the problem is the capital letter... I have an another question : preambleText and readmeText don't have the expected behavior when I load a package from Monticello, do you notice it ?
Regards, Samir.
On Jan 31, 2004, at 6:22 AM, Samir Saidani wrote:
I have an another question : preambleText and readmeText don't have the expected behavior when I load a package from Monticello, do you notice it ?
Those methods are used by SARBuilder, not by Monticello. When I need behavior on package load, I just use a class side #initialize method.
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Julian Fitzell -
Samir Saidani