# The following was supposedly scribed by # Bruno Postle # on Tuesday 21 September 2004 11:31 am: >The attributes I missed are: layer, color, object_style, linetype & >lineweight. =A0These are all very CAD/drafting specific and could >easily inherit default values if absent - Shouldn't they be optional >too? Possibly, but that complicates things. If the default for linetype is=20 'style', then the object_style should be required. Also, having some=20 items without layers while others have layers is going to throw grep=20 for a loop. This is the same sort of thing that makes me want rhizopod to not have=20 per-entity version attributes and such. I think a rhizopod directory=20 needs to present an interface which is as consistent and predictable=20 as possible. Two line entities of different versions within the same directory is =20 incompatible with this. Similar sentiments for units, copyright,=20 license, etc. That's why I think these things should only be defined=20 in "./drawing". This is what I've been calling the "grep litmus test". If I can't get=20 some information with an extremely simple grep and typeglob command,=20 then the spec isn't passing this test. e.g., the following should=20 tell me what layer ID's in this drawing contain lines: for line in `grep -l "^type: line" *.yml` do grep "^layer:" $line | sed 's/layer: \+//' done Getting the layer names is a little more complicated, but that's just=20 the way it is. We can get the filenames with something like this on=20 a pipe at the end of the above loop: perl -e '%a =3D map({chomp; $_ =3D> 1} <>); print join("\n", map({"layers/$_.yml"} keys(%a))), "\n";' \ > /tmp/layers And then, you can do this to get their names: for layer in `cat /tmp/layers` do grep "^name" $layer | sed 's/name: \+//' done Of course, there are more ways to do this, but the point is that you=20 can use very simple scripting and typeglobs to discover things about=20 a drawing. That's why the spec has the "# TYPGLOB" sections. These=20 reserve that typeglob as a namespace so that simple scripts are not=20 thrown-off by, for example, a directory getting passed as an argument=20 to grep. Note what happens to the above example if a "layer:" attribute is=20 missing from a line or if it is described in one file differently=20 than it is in the others. Now our simple commands have been exposed=20 as na=EFve. If the spec is predictable enough, na=EFve is okay. In=20 fact, in many cases it is much faster to type some combinations of=20 grep than to write some program which handles the defaulting of=20 missing options and etc. A homogeneous format doesn't require as=20 many conditionals, and therefore should be more attractive as a "my=20 first file format". Yes, this complicates inheritance and polymorphism, but those things=20 are complicated. I'm going to go out on a limb here and say that=20 rhizopod could be usable with inheritance and polymorphism while=20 simultaneously satisfying the grep litmus test. However, this means=20 that the code in Draft must look beyond the single entity to find=20 things like version and units. If that isn't an option, then=20 rhizopod can't do polymorphism and etc directly. =2D-Eric =2D-=20 Peer's Law: The solution to the problem changes the problem.