On Mon, 1 Mar 1999, Asger Alstrup Nielsen wrote:
> [How to handle the extendibility problem.]
> [Layout files on steroids or linked objects a la Gimp.]
>
> > A compromise or rather a combination of the two would be my favourite
> > choice. I think there should be /both/ an easy-to-use quick&dirty way to
> > get support for a new simple document class or environment, as well as a
> > more powerful set of tools for the complicated cases. But I think the
> > latter is more flexible as it would be the task of the objects to check the
> > configuration files.
>
> I propose this model:
> We let the layout files partially be a program written in our scripting
> language.
> LyX will provide a bunch of hooks for the various events that can occur with an
> inset.
> So, the layout files will be a bunch of records like the ones we have already,
> with a few new entries thrown in for the fun of it:
>
> Inset Foobar
> Color black;
> // lots of ordinary properties
>
> // And then the methods:
> OnInit { state = 0; }
> OnClick { for i=1 to state; print i; next i; }
> OnWrite { print state; }
> OnRead { read state; }
> EndInset
Yes, that'll do nicely for simple insets. I wouldn't want to write a
complex inset like a music, tree or Feynman diagram inset with that though.
Do you plan to have an internal API (i.e. functions and variables in this
scripting language that interfaces to the public members in the objects in
the compiled part) covering every public member in all the classes?
> > Actually, I'm doing things backwards here. The first thing to do is
> > obviously to define exactly how much and what an object (be that a heading,
> > an inset, whatever can be a part of a document) needs to know about the
> > rest of the programme, and how much the core needs to know about the
> > objects. Clearly defined interfaces between different parts of the design
> > could help up the development process, regardless of what method of
> > implementation we'll use. (Input methods should also be more separated
> > from LyXFunc::dispath I think, or LyXFunc in general for that matter; a
> > stateless dispatch() )
>
> You are proposing that we use the waterfall development model:
> Specification, implementation, testing, and then release.
I am? I don't think so.
The current development model seems to be: implement, release and then fix
bugs. What happened to `design' ?:-P
> I fear that this model is suboptimal: We will never finish the design phase.
> Rather, I think we should just begin and use an iterative development process.
> First understand and clean up the current code and design. Then add hooks in
> the best way we can, and develop the code incrementally: Use the spiral
> development model instead. This way, we will continuosly be able to validate
> our design in working code. We will be much better suited to evaluate design
> decisions, and have a clearer view of what we need in the different
> circumstances.
Of course we'll never finish the design phase! nor the implementation phase
etc. That's what iterative et.al. development methods is about. ;) I'm
not so naive as to think we'll get the design perfect in the first round,
but there should at least /be/ a first round of designing.
Franky, I don't see the point in spending time coding when I don't know
what I'm aiming at. I am reluctant to even touch 1.1 without having
something to work after. I'm too lazy for that! ;) I think laziness is a
fine virtue. Laziness is what has been the incentive for engineering ever
since the invention of the bow and arrow 25.000 years ago. (someone was too
lazy to run after the prey all day long, and invented something that would
do the most straining part of the running for him. =)
IMHO, a design that isn't documented is the same thing as no design at all.
We're not mind-readers; even if the one who implements something have a
plan with what he does, others can't be expected to guess out the design by
staring at the code, especially not if the code doesn't work and certainly
not if the code doesn't even exist yet.
Sometimes we forget how we were thinking 18 months ago when we worked with
something. The diff between `design' and `implementation' is what
constitutes a `bug.' If there is no design, what gets implemented will
only be useful by coincidence, and `bug' can't be defined. (nor can design
flaws be defined)
>
> > So, what would a spec for the interfaces look like? What methods/signals
> > should they have, and which part should handle which tasks? Anyone?
>
> This question is simply too hard to answer. Instead, let's just have a closer
> look at what we have, cut any the redundant bits, and try to make the design
> more ortogonal. Then, extend it the best way you can think of, and over time,
> we'll hopefully have a good design.
"Look! I made a...? a... programme! I wonder what it does!" %-D
I am aware it is a tough question, designing large software project is a
delicate task indeed. I am also aware of the importance of planning. I
was asking (still am) for internal interfaces because I don't see how else
we could work in parallel. (or do you plan to do it all on your own? ;)
Then naturally, in order to define internal interfaces, the blocks in
between which these interfaces shall be operating, must be identified.
It will cost a lot more in work effort to fix design flaws if they are
discovered during implementation than on the sketch table. Again, I'm far
too lazy to cheerfully hack away only to find out later on I have to revoke
large portions of my work becasue I and someone who's been working on some
other part has had incompatible plans for how the parts should interact.
I wish we could stop `hacking,' and start working methodically instead. :P
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
