[cad-linux-dev] Re: YAML file format - Optional attributes

  • From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
  • To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
  • Date: Tue, 21 Sep 2004 18:48:23 -0500

# 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.



Other related posts: