On Sat, 30 Oct 1999, Alexander Larsson wrote:
> Again, i think this is to speciallized to be in the generic zigzagline
> object. I think you should write your own object that has this. Then you
> could probably also remove some properties or rename them to more
> domain-specific names.
<rant>
specialised ? It's not because diagram type "foo" needs feature "bar" that
another folk, who wants to draw a type of diagrams currently unsupported
by dia, doesn't need that feature too. Without first cranking up emacs to
build a dozen times a couple hundred lines of code !
Of course, dia is great at building UML diagrams. Now, not everyone does
UML modeling, and dia doesn't claim to be an UML modeling tool (for which
it would dearly lack a code generator) but a generic, top-notch diagram
editor (which, in the specific case of UML, it is).
The problem is that once you want to draw something which is not present
in dia, you are stuck with either writing a new shape (quite easy, thanks
James), or forking of code, which is Bad.
(There is something shocking here :
donjon% wc line.c
722 1745 21842 line.c
come on, 722 lines to simply draw lines using generic, all-purpose helper
functions ?
And these 722 lines times 11 different line types (in fact, it's even
more) ? That's already 8k lines to maintain just for arrows ! Most of it
being persistency handling and GTK wrestling code, which while being
indeed "boilerplate" is nonetheless to be manually typed (AFAIK) and
manually maintained (of course)...
This is just insane.
There must be a way out !
> The code for an object isn't all that much, especially since most of them
> derive from helper classes that takes care of much work. Most of the code
> of most objects is just boilerplate anyway.
Boilerplate code is one of the most dangerous things out there. And it's
definitely code which should be written by humans.
Look at the patch you rejected : I added *one* property, a simple float
value. This new property implies a hundred lines of actually specific code
(which is not particularly well written nor optimised, it simply works).
Now to add this property, I had to touch no less than 15 other spots in
that file, virtually in half of the functions of that file. Most of these
additions are trivial, but must be kept in sync. And all this grunt work
is a compiler's work, not a human's.
(I'm not saying that there's a solution readily available ; less even one
easily adaptable into the current code base ; but it surely is possible
(and I could do it, if deemed reasonible) to write a helper program,
which given a description of all properties and persistent stuff of a
new object, would splat out all boilerplate code, ready to be inherited
by the actual object implementation (or overriden, if for instance the
dialog box doesn't look nice enough)).
Oh, well, forget that.
</rant>
-- Cyrille
------------------------------------------------------------------
Oh, my god ! I'm trapped into a V90 modem ! PGP ID: A879BEF8
