CampSmalltalk / Cypress

A cross Smalltalk dialect, disk-based package import/export format, inspired by the https://github.com/dalehenrich/filetree project.
MIT License
28 stars 1 forks source link

method file header #18

Closed mkobetic closed 11 years ago

mkobetic commented 11 years ago

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 commented 11 years ago

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" notifications@github.com To: "CampSmalltalk/Cypress" Cypress@noreply.github.com 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:
https://github.com/CampSmalltalk/Cypress/issues/18
janvrany commented 11 years ago

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" notifications@github.com To: "CampSmalltalk/Cypress" Cypress@noreply.github.com 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:
https://github.com/CampSmalltalk/Cypress/issues/18

— Reply to this email directly or view it on GitHub https://github.com/CampSmalltalk/Cypress/issues/18#issuecomment-16217960.Web Bug from https://github.com/notifications/beacon/BTeKxI_0bFOw-XPWQyOrf6b1fjqffTb25LnwiKBnCaDA3zemyXe8-pagyWmyvoec.gif

mkobetic commented 11 years ago

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.