On Sat, 30 Oct 1999, Cyrille Chepelov (home) wrote:
> 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>
Heh.
> There must be a way out !
Well, there is. I think the solution to this problem (I agree it *is* a
problem) is to make helper function and macros that reduce the amount of
boilerplate and makes it easier to maintain and change stuff.
> > 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.
I agree partly here. Unneccesary boilerplate isn't very good.
> 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.
Well, what you say is true. But the reason i don't like the way of
solving this is:
1) It doesn't scale. Most probably a lot of connection types for different
kinds of objects will pop up as more dia objects get written. If each of
these add just *one* property to the line object in order to draw their
special stuff the Line object will be very big and bloated. The code will
be large and hard to understand, and the saved files will be very big. The
user will also have a hard time using the Line property dialog since it
contains very many options and properties.
2) It's a developer solution, not a user solution. (At least given how i
think Dia should be used, which might not be true of course, but is
nevertheless my idea of Dia.)
The user wanting to do a Entity Relationship diagram (taking an example
currently in Dia), so he selects the ER sheet. He then wants to create a
participation between a Relationship and an Entity. To do this he selects
the Participation object and connects the two other objects. But since he
wants it to be a "total" participation he double clicks on the
participation and enables the "total" checkbox in the properties dialog.
He might not even know (or remember) how total participations are rendered
in the diagram, and he certainly wouldn't be interested in (i.e.) wavy
lines, which are never used in ER diagrams. He doesn't even want to select
between "single" or "double" lines, because it would make it harder to
understand how to create a total participation.
I understand your point in that this wouldn't make Dia an ideal editor for
diagram types that are not yet supported. I hope that in time most diagram
types will be supported.
> (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)).
I don't know if this is the best solution. I'd rather have more support
code that takes out the repetitiveness of the code. Stuff like:
* Macros to define the "standard" function declarations (given the object
name to use as prefix and the typename for the object).
* Table-driven load and save functions. These would make it easier to
add properties.
* Helper functions to create properties dialogs.
* Move possible objects from code to custom xml shapes.
What do you think about this?
/ Alex
