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

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..

On 29 June 2012 17:15, Camillo Bruni <[hidden email]> wrote:
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

Camillo Bruni-3 wrote

we might even put methods in multiple categories

Yes!!! The sooner the better :)

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:
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