method file header

[mkobetic]

We've defined the method file header to be fairly rigid, currently it must have exactly two fields: notice and category. Since it's nicely delimited with the double-quote lines, I don't really see a reason to be so rigid about it.

I currently have one issue which is that it is normal that I can't infer a suitable copyright line for a given VW package. The best I can do at that point is to emit just and empty notice line. I think it would be better to omit it entirely.

Also a bit more flexibility would allow accommodating something like squeak/pharo need to capture the initial/timestamp and such.

Is there a reason why we decided to go so rigid? I don't remember.

[dalehenrich]

I don't recall the details either ... perhaps we were trying to avoid junking up the method source with a bunch of meta data?

Regarding the timestamp and user stuff, I think we are better off leaning on git for recording that information ... git knows more about the history of the the method than (blame) than a mere timestamp ...

With regards to the copyright stuff, IIRC the "requirement" is that for proper copyright specification, one needs to include copyright information in "each file" and that was the reason that we added the copyright line at all ...

So perhaps I have reconstructed the argument for two lines ... we need the category information and copyright information in each file and we really don't need anything else....

I know that in the conversion period where Smalltalkers are not in the habit of including any copyright information with their package/projects that we'll end up with empty lines in a lot of files .... but for the folks that want to "do the right thing" (or at least what the non-lawyers amongst us interpret as the "right thing) we need to reserve room for the copyright information ...

The fact that we've got the leading notice: and category: implies that we could be less rigid about requiring that the lines be present at all ...

Does it make sense that the minimal header is two lines starting with a single double quote?

Dale

----- Original Message -----
| From: "Martin Kobetic" [email protected]
| To: "CampSmalltalk/Cypress" [email protected]
| Sent: Wednesday, April 10, 2013 7:19:11 PM
| Subject: [Cypress] method file header (#18)
|
| We've defined the method file header to be fairly rigid, currently it must
| have exactly two fields: notice and category. Since it's nicely delimited
| with the double-quote lines, I don't really see a reason to be so rigid
| about it.
|
| I currently have one issue which is that it is normal that I can't infer a
| suitable copyright line for a given VW package. The best I can do at that
| point is to emit just and empty notice line. I think it would be better to
| omit it entirely.
|
| Also a bit more flexibility would allow accommodating something like
| squeak/pharo need to capture the initial/timestamp and such.
|
| Is there a reason why we decided to go so rigid? I don't remember.
|
| ---
| Reply to this email directly or view it on GitHub:
| #18
|

[janvrany]

I do recall because I was the one who wanted such a rigid spec of a
header. My arguments were (and still are):

1. do not mess with different way how specify various metadata, there's
   already the json stuff...argh, sorry, ston stuff :-)
   However, we decided to leave method category there for historical
   reasons and copyright must be there just because lawyers like it.
2. its easy to parse. four #nextLine do it, no need to search for
   opening/closing "

In my opinion arguments are still valid so I vote for keeping spec rigid
in this particular point.

Regarding timestamps and other metadata - they should go .ston files.

Jan

On 11/04/13 07:53, Dale Henrichs wrote:

I don't recall the details either ... perhaps we were trying to avoid
junking up the method source with a bunch of meta data?

Regarding the timestamp and user stuff, I think we are better off
leaning on git for recording that information ... git knows more about
the history of the the method than (blame) than a mere timestamp ...

With regards to the copyright stuff, IIRC the "requirement" is that for
proper copyright specification, one needs to include copyright
information in "each file" and that was the reason that we added the
copyright line at all ...

So perhaps I have reconstructed the argument for two lines ... we need
the category information and copyright information in each file and we
really don't need anything else....

I know that in the conversion period where Smalltalkers are not in the
habit of including any copyright information with their package/projects
that we'll end up with empty lines in a lot of files .... but for the
folks that want to "do the right thing" (or at least what the
non-lawyers amongst us interpret as the "right thing) we need to reserve
room for the copyright information ...

The fact that we've got the leading notice: and category: implies
that we could be less rigid about requiring that the lines be present
at all ...

Does it make sense that the minimal header is two lines starting with a
single double quote?

Dale

----- Original Message -----
| From: "Martin Kobetic" [email protected]
| To: "CampSmalltalk/Cypress" [email protected]
| Sent: Wednesday, April 10, 2013 7:19:11 PM
| Subject: [Cypress] method file header (#18)
|
| We've defined the method file header to be fairly rigid, currently it must
| have exactly two fields: notice and category. Since it's nicely delimited
| with the double-quote lines, I don't really see a reason to be so rigid
| about it.
|
| I currently have one issue which is that it is normal that I can't infer a
| suitable copyright line for a given VW package. The best I can do at that
| point is to emit just and empty notice line. I think it would be better to
| omit it entirely.
|
| Also a bit more flexibility would allow accommodating something like
| squeak/pharo need to capture the initial/timestamp and such.
|
| Is there a reason why we decided to go so rigid? I don't remember.
|
| ---
| Reply to this email directly or view it on GitHub:
| #18
|

—
Reply to this email directly or view it on GitHub
#18 (comment)
Bug from
https://github.com/notifications/beacon/BTeKxI_0bFOw-XPWQyOrf6b1fjqffTb25LnwiKBnCaDA3zemyXe8-pagyWmyvoec.gif

[mkobetic]

ok, it seems that we don't see a need for additional method properties and notice should not be empty. so let's close this with the confirmation that the spec stays as is in this regard.