LDraw.org Discussion Forums

Full Version: Call for votes: Drop 64-character part title limit
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.



Change http://www.ldraw.org/article/398.html to remove the struck-through text:

Quote: PartDescription is the descriptive name of the part (limited to 64 characters). If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (Needs Work)" (without the quotation marks) can be added to the end of the description. Please note that the full description including " (Needs Work)" is limited to 64 characters, so this decreases the usable portion of the description to 51 characters. If the description includes "(Needs Work)", a comment must be added to the file immediately following the official header describing the work that needs to be done.
I vote yes.
I vote YES
I vote yes.
Yes
Voting has been open more than one week, and there are four votes in favor. The motion has passed.

I do not have write access to the standard; could one of the admins please update it accordingly?

Thanks,
Allen
Just to be clear, I am only abstaining because an unlimited line length is impractical to implement in the Parts Tracker software (in fact in any software), so I will need to make an arbitrary decision on a number that I consider reasonable. I would rather it have been defined for me.
Given that none of the other fields in Header Specification have any length limit, nor does linetype 0 in the official spec, this limitation of the Part Tracker software was not obvious. Personally, I think
http://forums.ldraw.org/showthread.php?t...72#pid7972' Wrote: [ -> ]Tim has the best suggestion
if the Part Tracker isn't using dynamically-allocated strings: just set a large limit unlikely to be bumped into.

While plenty of code has been written in which dynamic string lengths would be a nightmare, I disagree that unlimited-length strings are impractical to implement in any software. True, stack-based char buffers in C were a pain, but everything I've used in years has abstracted strings' memory storage so length is constrained only by the amount of available RAM. Unlimited-length strings are widely available, and are usually built-in to your API or language of choice.

Allen
Orion,

looking at:

http://www.ldraw.org/article/398.html
http://www.ldraw.org/article/218.html

or the Admin log it seams that this has still to be changed. Please confirm.

w.

LEGO ergo sum