Martin Kupec <martin.ku...@kupson.cz> writes: > On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote: >> >> Trying to model things that aren't layers as if they were layers is >> >> one common mistake in this kind of tool. Equally common is leaving out >> >> layers: the insulating layers in a PCB are just as important as the >> >> copper, and have their own properties (shape, thickness, material, >> >> etc.). They're a critical part of the layer stack. >> >> >> >> The description language needs to be able to express "feature p in >> >> layer x is aligned with feature q in layer y" in order to build up >> >> composites. This is the geometrically sensible way to describe the >> >> result of drilling through several layers. But the geometric >> >> description language should not be tied to any particular fabrication >> >> procedure. >> > >> > This is all too physikal for my taste. >> >> I assert that if you do it any other way, you wind up with the >> following catastrophe: the code for every layer type needs to >> incorporate a specific definition of its interaction with the code >> for every other layer type. A total collapse of factoring, poisoning >> flexibility and maintainability. But if layers correspond to actual >> geometric layers, this can be avoided, I believe.
What I like with PCB is that there is very little interaction. Only when special actions are called, the interactions are invoked. E.g., when I hit the O key, the connectivity is evaluated. For that I only need to know which layers are conductive and what vias connect which layers. > Actually what I am trying to do, is to have concept so layers don't > interract with layers of different type. The composits are a bit > problem, because I would need to consider more layers when performing any > action, but I think that it can still be interaction with object on the > same layer. I do not understand what problems you see with composits. A layer consists of the union of all shapes on any level of the composits hierarchy. Composits may be referenced at multiple positions, so those shapes appear multiple times. When a shape is modified in a composit, it may affect all copies simultaniously, or the composit will be duplicated (copy on write), depneding on an attribute or explicit user action. > So, i.e., If we would have 'hole' layer. I would have check, that holes > on hole layer are not intersecting. And also check the intersection of > attached shapes on each layer. But all what can happen is that some > layer will yell that something bad happend and I should cancel my > action. Where do you want to attach holes. To layers, like John proposes? To shapes on a layer? Or as independent entities, like they are now? -- Stephan _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user