On Dec 20, 2010, at 20:29 PM, Wayne Stambaugh wrote: > On 12/20/2010 1:42 PM, Dick Hollenbeck wrote: >> On 12/14/2010 04:49 PM, Wayne Stambaugh wrote: >>> I made some ,inor changes to clarify inherited vs base part and changed >>> LPID names reflect local naming convention as suggested by Dick. >>> >>> Wayne >> >> >> Wayne and others, >> >> >> I coded the initial major portion of DIR_LIB_SOURCE this weekend. I believe >> the design is still >> holding water, so far. >> >> >> The only thing that has come up is this age old issue of content in >> container, and names. >> >> Let me generalize, so you can see it is not specific to this design. >> >> Assume you have a C++ file, and you decide to put the name of the file INTO >> the file as a string. >> >> You load that C++ text file, and save it by another name. >> >> The file now lives in two *containers*. >> >> >> >> 1) The text editor is a container, and it assigns a name to the text file in >> memory. >> >> >> 2) The filesystem is a container, and it assigns a name to the text file on >> disk. >> >> >> Each container has its own understanding of the name of the content (i.e. >> text file). A >> disagreement has happened. And it is not about the name in the editor and >> the name on disk. >> >> It is about the name IN THE FILE, and the name in the editor and on disk. >> >> >> >> >> Either of the two examples of "content (text file) within container" would >> suffice to make my point: >> >> >> as long as you put the name of the file in the file, there is always >> the potential for a disagreement between what the file's container >> thinks the content is named, and what the contained name says. >> >> >> Therefore, we might want to re-think our Sweet token that we referred to as >> "NAME" >> >> (part NAME [extends LPID] >> .. >> ) >> >> and either drop it, since the Sweet string will always be in some kind of >> container, or realize that >> this is not *really* the name of the part, the container will always chose >> that. > > I actually considered this when I wrote the specification. I don't remember > why I chose to include NAME in the part syntax. I think it's a great idea. > Using the file name as the part name makes sense to me.
It has both advantages and disadvantages. The advantage would be that you do not need to "scan/read" the file to know the component, but (in my opinion) the cons outweigh the advantage. The disadvantage I see has to do with the different filesystems, case-sensitivity and illegal characters. Now the filename could hint the part, but the only requirement for a filename is that it is unique within the directory. Kind regards, Martijn > >> >> >> A useful comprimize is to conceptually or actually change NAME to >> SHORT_DESCRIPTION, but if you have >> a description elsewhere, a short description may not be needed at all. > > A description (short or otherwise) seems like a good candidate for a property. > I'm not sure if it should be a reserved property or a user definable property. > >> >> Think about it. The only time when the container will not name the content, >> may be on the clipboard. > > Would you even need the name in the clipboard? If you are pasting into > another > part file, it will take the name of the new part file. You may need to name > them when they become components in a schematic but that would be part of the > schematic file format. > >> >> A fast answer is probably a wrong answer. I've been thinking about it for a >> day and still need more >> time to state the best solution. > > Let me know so I can update the specification. I have already made the > changes > for providing pin and gate swapping flags to be passed to external tools. I > want to keep the specification synced with the code as much as possible to > avoid confusion. > > Wayne > >> >> I just know that the problem will exist as we now have things, and as >> stated, it is not a problem >> unique to this design. >> >> The container's name will always really dominate, since that is the >> mechanism used to find units of >> content. >> >> Dick >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
