LDraw.org Discussion Forums
[LSC Request] End of header meta command - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: [LSC Request] End of header meta command (/thread-8081.html)

Pages: 1 2 3 4 5 6 7 8 9


Re: [LSC Request] End of header meta command - Ben Supnik - 2014-01-07

I agree that the burden of proof for format extensions needs to be for why it is necessary.

But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

(If you are right and the header can be found strictly by existing algorithm, then formalizing that algorithm is valuable.)


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-07

Ben Supnik Wrote:But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

I hope people realise that example was given in my original proposal and was the main reason for the proposal...

Tim Gould Wrote:That way codes like LDMakeList of LDFind can know which comments are useful notes for the header (eg. in a needs work file) and which are just separators of the different part components (eg. 0 // Studs).

Tim


Re: [LSC Request] End of header meta command - Philippe Hurbain - 2014-01-07

Quote:Except it often gobbles up comments from within the part data.
...and even BFC invertnext if it's the first line in file


Re: [LSC Request] End of header meta command - Steffen - 2014-01-07

Ben Supnik Wrote:But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

Yes, that's true. That's the only thing that cannot be achieved by the current syntax.
However: let me counter this with the argument that this special case, where in-file comments
start right after the header, is very seldom. It only happens on exhaustively documented
parts, and my guess is that of all our currently official files this affects at most 10 or 20 or so files.
This doesn't convince me that the new token really is required. It does not really hurt if
these some extra comments are parsed as well, in these few special cases.
Especially since LDFind anyway indexes the whole file, which makes it more powerful.
We're talking here about a small beautification for a vanishing amount of files affected.
I cannot see the benefit. The small gain is outweighed by all the hassle of introducing the new language element.
This is my personal opinion.
In file format specification, minimalism is the way to go. It keeps the complexity of your format small.
If you too liberally add syntax elements, you end up with something as syntax-complex like perl.
You will not want to write an error-free parser for that...


Re: [LSC Request] End of header meta command - Steffen - 2014-01-07

well, this can be easily repaired _without_ a new token.
it's a simple special case missing in the PT's logic.


Re: [LSC Request] End of header meta command - Steffen - 2014-01-07

Tim Wrote:This argument is basically "because you offered a compromise your proposal obviously has no merit".
Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.
If the new syntax is optional, and you anyway have to implement fallback code, then you could use the fallback code from the beginning. That proves the redundancy of the new syntax.


Re: [LSC Request] End of header meta command - Philippe Hurbain - 2014-01-07

Quote:If the new syntax is optional, and you anyway have to implement fallback code, then you could use the fallback code from the beginning. That proves the redundancy of the new syntax.
That's a point. But it doesn't solve the startup comments issue...


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-07

Steffen Wrote:
Tim Wrote:This argument is basically "because you offered a compromise your proposal obviously has no merit".
Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.

On the contrary. I think it is close to the worst counterargument possible. Especially since I never mentioned simplification of coding so it was a side show anyway from my perspective.


Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-07

The issue affects close to every part I ever submit because, like a well-behaved programmer, I comment as much as possible in my files. And after editing a moderately complex but uncommented part recently, I'm very glad I do comment.

So let me summarise the pros.

1) There is minimal hassle in introducing a simple meta like 0 !END_OF_HEADER.
2) Such a simple meta will be parsed correctly by old software, and thus its implementation would not be compulsory.
3) Part authors who use it could add more verbose comments in their files, making re-editing easier.
4) We thus avoid obsfucated LDraw and improve the quality of parts.

On the other hand, for cons we have

1) It is new.

Tim


Re: [LSC Request] End of header meta command - Santeri Piippo - 2014-01-07

I kind of believe we should try to keep things simple. I'd suggest make END_OF_HEADER mandatory if the body starts with a type-0-line, even if it were a BFC or TEXMAP statement. Thus the end of header is defined as either the first non-type-0 or END_OF_HEADER. No need for complex rules.

This is coming from someone who thinks allowing clock-wise winding for BFC and the ability to change a part's winding mid-file are stupid things, though. But I think we should keep things well-defined so I'm all for this meta-command as well as any NEEDS_WORK meta command.