kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp