On 17 Sep 1999 17:56:07 +0200, Lars Gullik Bj°nnes wrote:
>"Arnd Hanses" <[EMAIL PROTECTED]> writes:
>
>| It won't help anybody, if you still continue to export all your soon
>| 10,000 global inter-module interface symbols; even now you have 3026
>| public symbol exports (functions and variables) in LyX 1.0.x global
>| name space.
>
>As said. 1.0.x is defunct in this discussion. If you want to continue
>get your facts from 1.1.x it is in that direction that we are going.
And this direction means more features, more flexibility, hence more
complexity.
My point here is easy maintenance and extensibility:
If you don't strictly reduce the impact of complex details, limiting
their scope - e.g. by use of 'programming by contract' style door
guards - to a split apart and shielded region of the (in fact still
monolithic) code base, producing a bug-free LyX will simply involve too
much work, too much frustration, because too many people have to take
too many details into account. You'll need years of LyX experience to
make things work, you'll have to keep too many details in your mind.
>
>btw. Have you every run a "nm libwhatever.so"
>there are hundreds and
>thousends of exported symbols. I don't get your point about the public
>symbol exports.
Yes.
Internally you'll see thousands of libforms' globally exported symbols,
which are opaque for the programmer, who is not interested in the
library's inter-module interface but only in the reduced inter-library
application programmer interface.
Do afterwards for instance 'nm --dynamic --defined-only libforms.so'.
Then you'll see the difference:
- There you have for libforms roughly only some 900 dynamic
exports, likely less (no Linux around at the moment). Those are the
interfaces (, which are easy to be grouped, so that the actual
interfaces an application programmer has to take into account and
bother about is much lower).
This is the scheme I propose to consider to be adapted for LyX:
- Reduce the overall LyX developer interface, make the
implementation dependent inter-module interfaces opaque, with the
exception of a strictly reduced number of exported abstract data
objects (ADT) and LyX 'plugin' developer function interfaces.
Actually much of this has already been done, but stricter modularity,
enforced by 5 or 6 shared dynamically linked libraries would at first
involve considerable work in
(a) defining the absolutely essential LyX 'plugin' developer
interface and
(b) implementing the 'programming by contract' door guards.
Afterwards progress will be much faster, because it is easy to isolate
problems and write extensions, when you only have to bother about a
fraction of the actual (strictly modularized) code base. Fixing,
extending, perfomance tuning of one library will leave others
unaffected, you even won't need to relink LyX, if you are binary
compatible.
Probably you think this will be too painful to achieve now. In the
light of constantly increasing overall complexity the resistence will
melt in the end.
Greets,
Arnd
