Re: gEDA-user: Yet another netlister

["A.Burinskiy" <alexbour@xxxxxxxxx>]

John,

Do you mean that one day source= attribute is reference to schematic, 
another day it is something else? We have to stick to some reasonable 
meaning of all attributes, at list to be able to exchange libraries and 
collect our work over the years, isn't it?
Talking about ynetlist: it has exactly front, inner, and backend. I call 
it component/net collection, symbol elaboration, output netlist. By 
modifying only output I may create any netlist. But yet I do not see a 
reason why user should mangle with programming.... It is programmer 
responsibility to cover all needs.

Alex.


On 08/09/2009 04:43 PM, John Doty wrote:
> On Aug 9, 2009, at 3:19 PM, Kai-Martin Knaak wrote:
>
>    
>>      
>>> For me that's not the issue: the issue is that you're putting yet
>>> another gnetlist behavior out of reach of back end control.
>>>        
>> You mean, the behavior of a netlister should depend on the order of
>> components in the *.sch file?  Please give an example if you seriously
>> think so.
>>      
>
> No. The order isn't the issue. The issue is that the front end should
> not arbitrarily restrict which attributes the back end gets to see.
> In this case the arbitrary selection is based on order, but it's the
> arbitrariness that's the problem. not the order.
>
> A back end that processes hierarchy on its own should see all of the
> source= attributes. A more sophisticated BOM than we have might
> usefully choose from multiple manufacturers' part numbers.
>
> But remember that neither you nor I can anticipate what information a
> future back end might need. Don't focus narrowly on specific
> scenarios. Let the back ends decide what they need to see. Don't hard
> wire decisions in the front end code. In this case, remove the
> arbitrary selection from the hard wired code and put it in the middle
> layer, where the back end can bypass it as needed.
>
> This kind of flexibility is gEDA's greatest strength. DO NOT DAMAGE
> IT. Don't hard wire anything new. Instead, let's improve it, move the
> decisions to the middle layer and back ends.
>
> John Doty              Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd@xxxxxxxxx
>
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>    


-- 

Alexander Burinskiy
IC design
San Jose, CA, 95129
(408)230-3458 (cell)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user