hi dale,
I just noticed that you put the method's protocol inside the method source when you fileout stuff with filetree. IMO this has some drawbacks when using git tools. If you recategorize the method, git won't be able to show this, since the contents of the source file in git change (namely the protocol on the first line of the source file). Putting the methods into a subfolder with the name of the category would solve the git tracking issue, renames would now be properly detected by git. Was this decision taken on purpose to avoid issue with strange folder names that are not supported on all platforms? best cami |
Hey Cami,
I've played with subfolders before and I'm not sure that using subfolders works that well ... Obviously it is a good thing for making method categorization very clear, but not so well for other things. For me there's a point where you can put too much structure on disk ... just like in the Browser, it is awfully convenient to have an '-- all --' category and I've found that when I am navigating the directory structure on GitHub or on disk, that the extra level of indirection is very frustrating ... I don't have categories memorized (neither class nor methods) so if we used directory structure (and I did at one point in time) for categories I would spend all my time poking into and out of the category directories looking for things (and I did) ... I use github for 90% of my (non-image-based) navigation and the extra categories would have made that unbearable. So for me this was the overriding argument against using subfolders. In retrospect, now that I've added the methodProperties.json file, we could have included the method category information there instead of embedding it in the method source file. With all of that said, it is worth opening up this discussion on the Cypress issue list[1], where the folks from other dialects can weigh in, since all of us have to coordinate any changes to the common structures. Dale [1] https://github.com/CampSmalltalk/Cypress/issues ----- Original Message ----- | From: "Camillo Bruni" <[hidden email]> | To: [hidden email] | Sent: Friday, June 29, 2012 12:12:09 AM | Subject: [Metacello] filetree: method protocol | | hi dale, | | | I just noticed that you put the method's protocol inside the method | source | when you fileout stuff with filetree. IMO this has some drawbacks | when | using git tools. | | If you recategorize the method, git won't be able to show this, since | the | contents of the source file in git change (namely the protocol on the | first | line of the source file). | | Putting the methods into a subfolder with the name of the category | would | solve the git tracking issue, renames would now be properly detected | by | git. | | Was this decision taken on purpose to avoid issue with strange folder | names | that are not supported on all platforms? | | best | cami | |
On 2012-06-29, at 16:05, Dale Henrichs wrote: > Hey Cami, > > I've played with subfolders before and I'm not sure that using subfolders works that well ... > > Obviously it is a good thing for making method categorization very clear, but not so well for other things. > > For me there's a point where you can put too much structure on disk ... just like in the Browser, it is awfully convenient to have an '-- all --' category and I've found that when I am navigating the directory structure on GitHub or on disk, that the extra level of indirection is very frustrating ... > > I don't have categories memorized (neither class nor methods) so if we used directory structure (and I did at one point in time) for categories I would spend all my time poking into and out of the category directories looking for things (and I did) ... I use github for 90% of my (non-image-based) navigation and the extra categories would have made that unbearable. So for me this was the overriding argument against using subfolders. point taken :) > In retrospect, now that I've added the methodProperties.json file, we could have included the method category information there instead of embedding it in the method source file. right, that is indeed better, we might even put methods in multiple categories.. > With all of that said, it is worth opening up this discussion on the Cypress issue list[1], where the folks from other dialects can weigh in, since all of us have to coordinate any changes to the common structures. > > Dale > > [1] https://github.com/CampSmalltalk/Cypress/issues > > > ----- Original Message ----- > | From: "Camillo Bruni" <[hidden email]> > | To: [hidden email] > | Sent: Friday, June 29, 2012 12:12:09 AM > | Subject: [Metacello] filetree: method protocol > | > | hi dale, > | > | > | I just noticed that you put the method's protocol inside the method > | source > | when you fileout stuff with filetree. IMO this has some drawbacks > | when > | using git tools. > | > | If you recategorize the method, git won't be able to show this, since > | the > | contents of the source file in git change (namely the protocol on the > | first > | line of the source file). > | > | Putting the methods into a subfolder with the name of the category > | would > | solve the git tracking issue, renames would now be properly detected > | by > | git. > | > | Was this decision taken on purpose to avoid issue with strange folder > | names > | that are not supported on all platforms? > | > | best > | cami > | |
On 29 June 2012 17:15, Camillo Bruni <[hidden email]> wrote:
> > On 2012-06-29, at 16:05, Dale Henrichs wrote: > >> Hey Cami, >> >> I've played with subfolders before and I'm not sure that using subfolders works that well ... >> >> Obviously it is a good thing for making method categorization very clear, but not so well for other things. >> >> For me there's a point where you can put too much structure on disk ... just like in the Browser, it is awfully convenient to have an '-- all --' category and I've found that when I am navigating the directory structure on GitHub or on disk, that the extra level of indirection is very frustrating ... >> >> I don't have categories memorized (neither class nor methods) so if we used directory structure (and I did at one point in time) for categories I would spend all my time poking into and out of the category directories looking for things (and I did) ... I use github for 90% of my (non-image-based) navigation and the extra categories would have made that unbearable. So for me this was the overriding argument against using subfolders. > > point taken :) > >> In retrospect, now that I've added the methodProperties.json file, we could have included the method category information there instead of embedding it in the method source file. > > right, that is indeed better, we might even put methods in multiple categories.. Indeed, that's how I've always thought of categories - tags. IIRC, GNU Smalltalk uses pragmas to describe the metadata. Ah, yes: http://smalltalk.gnu.org/project/issue/515 shows foo [ <category: 'example'> ^'foo' ] frank >> With all of that said, it is worth opening up this discussion on the Cypress issue list[1], where the folks from other dialects can weigh in, since all of us have to coordinate any changes to the common structures. >> >> Dale >> >> [1] https://github.com/CampSmalltalk/Cypress/issues >> >> >> ----- Original Message ----- >> | From: "Camillo Bruni" <[hidden email]> >> | To: [hidden email] >> | Sent: Friday, June 29, 2012 12:12:09 AM >> | Subject: [Metacello] filetree: method protocol >> | >> | hi dale, >> | >> | >> | I just noticed that you put the method's protocol inside the method >> | source >> | when you fileout stuff with filetree. IMO this has some drawbacks >> | when >> | using git tools. >> | >> | If you recategorize the method, git won't be able to show this, since >> | the >> | contents of the source file in git change (namely the protocol on the >> | first >> | line of the source file). >> | >> | Putting the methods into a subfolder with the name of the category >> | would >> | solve the git tracking issue, renames would now be properly detected >> | by >> | git. >> | >> | Was this decision taken on purpose to avoid issue with strange folder >> | names >> | that are not supported on all platforms? >> | >> | best >> | cami >> | > |
Administrator
|
In reply to this post by Camillo Bruni-3
Yes!!! The sooner the better :)
Cheers,
Sean |
On 2 July 2012 03:35, Sean P. DeNigris <[hidden email]> wrote:
> > Camillo Bruni-3 wrote >> >> we might even put methods in multiple categories > > Yes!!! The sooner the better :) For those systems that don't support multiple categories (and I _like_ multiple categories), what shall we do? Monticello uses categories to indicate package membership, so given a method categories as #('accessing' *Foo), we'd want to say "this belongs in '*Foo'". frank > -- > View this message in context: http://forum.world.st/filetree-method-protocol-tp4637202p4637669.html > Sent from the Metacello mailing list archive at Nabble.com. |
>>> we might even put methods in multiple categories
>> >> Yes!!! The sooner the better :) > > For those systems that don't support multiple categories (and I _like_ > multiple categories), what shall we do? Monticello uses categories to > indicate package membership, so given a method categories as > #('accessing' *Foo), we'd want to say "this belongs in '*Foo'". Symbolic links are supported in git, so it may just be an idea to use that. If we add sub directories for all the method categories, we could symlink inside that directory to the method file. For example, if we have: repository/Foo.package/Bar.class/instance/bar.st we could have repository/Foo.package/Bar.class/instance/accessing/bar.st -> ../bar.st and repository/Foo.package/Bar.class/instance/fly/bar.st -> ../bar.st I don't think it's necessary to do something about *Foo because the Foo.package should contain bar.st. Or am I missing the point here? It seems as if we have a one to one mapping for class categories and packages in the way we currently work. Does GNU ST's category pragma map to category or a method 'protocol' in Squeak / Pharo? Or is there a mix of concepts regarding what a category is now? Otto |
On 2 July 2012 15:02, Otto Behrens <[hidden email]> wrote:
>>>> we might even put methods in multiple categories >>> >>> Yes!!! The sooner the better :) >> >> For those systems that don't support multiple categories (and I _like_ >> multiple categories), what shall we do? Monticello uses categories to >> indicate package membership, so given a method categories as >> #('accessing' *Foo), we'd want to say "this belongs in '*Foo'". > > Symbolic links are supported in git, so it may just be an idea to use > that. If we add sub directories for all the method categories, we > could symlink inside that directory to the method file. For example, > if we have: > > repository/Foo.package/Bar.class/instance/bar.st > > we could have > > repository/Foo.package/Bar.class/instance/accessing/bar.st -> ../bar.st > and > repository/Foo.package/Bar.class/instance/fly/bar.st -> ../bar.st > > I don't think it's necessary to do something about *Foo because the > Foo.package should contain bar.st. Or am I missing the point here? I'm thinking about PackageBrowsers, PackageInfo instances, Monticello tools and the like, which expect extension methods to be in *Foo categories. > It seems as if we have a one to one mapping for class categories and > packages in the way we currently work. Does GNU ST's category pragma > map to category or a method 'protocol' in Squeak / Pharo? Or is there > a mix of concepts regarding what a category is now? I think that's a very good question to answer. As far as I can see from their syntax, they have a method in one (and only one) category - they use a <category: 'accessing'> pragma - but I don't know how baked that is into their toolchain. Does anyone on the list have any gst experience? frank > Otto |
Free forum by Nabble | Edit this page |