[cad-linux-dev] Entity types (longish)
- From: Massimiliano Mirra <mmirra@xxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Fri, 19 Dec 2003 06:33:13 +0100
You'll probably want to read this only if you're interested in the
ongoing development of a CAD system. I've been thinking a bit about
entity types with regard to our recent IRC
chats. (http://absurd.kozicki.pl:8435/Cad-Linux/cddf/Irc.Logs, #cadfs
on irc.freenode.net).
It's just rambling and not strictly related with what I'm working on
at the moment (which is the presentation of propertized information in
dynamic views through the file system), so feel free to discard as
much as you want.
+ + +
Trying to enumerate entity types and then saying `these are the types,
everything else is not', is something that worries me a bit.
When, after a world whose laws only deal with `circles' and `squares'
and such has been built, someone comes along with a compelling reason
for `parabola' to be an entity type and have its laws too, the thought
is going to be `damn, how many weeks will that take?' and the
subsequent work long and dirty.
I've yet to see something, that is designed around a finite set of
`slots' in which to classify things, be extended cleanly. If this
seems a theoretical issue, think of those first 640KB in your PC's
memory or of those `logic' partitions among the `primaries'.
While I don't think every possible scenario a software might encounter
can be foreseen, I'd like to build at least some basic extensibility
into the system that takes away the danger of the `finite set of
slots'.
I'd like the entity system to take the same step a program takes when
it evolves from using a big static storage (think a C array) to a
dynamically growing/shrinking storage (think a linked list or a tree).
What is a geometric entity anyway?
To me it's a set of points and lines kept together by a named idea.
When a set of points and lines drawn on a piece of a paper fits a
certain visual idea of ours, we have something that we call `circle',
`square', etc.
The interesting thing is that how many types of entity we perceive is
not a fixed quantity. A long time ago on a piece of paper there were
only `circles' and `curves'... today, on that same piece paper, there
are `ellipses', `parabolas', `hyperbolas'. The piece of paper hasn't
changed, and yet there are more things on it.
We can handle that parabola in a useful way because we have an idea of
how it's created and how it works. If it were just one another bunch
o' points, we could rotate it, translate it, scale it... whatever you
could do with any stupid bunch o' points, but nothing else. A
parabola, though... you can modify it in new ways because you know the
glue that keeps those points together.
So, we as humans have the extensibility I'm looking for.
Sadly, it seems many programs remain stuck at the level of children
who can only deal with basic concepts, and if you want them to deal
with more complex ones, you have to provide them the stuff in a
simpler form (e.g. a script that generates the lines and the points
for that nice parabola), hoping that they won't mess too much with it.
But even then, you'll be limited in the number of things you can tell
those children to do. You cannot tell them, for example: `hey,
flatten that parabola'. No, you have to generate a whole new,
flattened, parabola for them, and hand it to them in the form of the
dreaded bunch o' points.
Doesn't seem terribly useful to me.
Coming back to us humans for a moment (since there's obviously a thing
or two to learn here), we have: a name, and an idea for
producing/recognizing a visual representation. Trying to model that
in the bytes land, I'll drop the `recognizing' part for semplicity's
sake and say: a name and at least a procedure for producing a visual
representation.
Example:
Name of the entity type: circle.
Creation method: center and radius
Parameters: x and y of center, length of radius
Creation method: three points
Parameters: x and y of three points
Creation method: two tangent lines
Parameters: x and y of two points of the first line and of the second
Name of the entity type: square
Creation method: center and side
Parameters: x and y of center, length of side
...and so on.
Now, if each creation method is a function in a library, or a program
in a directory, or something equally dynamically growable/shrinkable
(as opposed to a fixed core of geometric functions in a CAD engine!),
adding new entity types becomes as easy as adding one more function or
program. And these will be first-class citizens, not wandering points
unaware of their identity as a whole.
And when someone will come along with a compelling reason for parabola
to be an entity type, instead of `damn, how many weeks will this
take?', the thought might just be `I'll throw that in before the
meeting, it's still half an hour before it'.
Other related posts:
