Re: [Texmacs-dev] enums patch

[Joris van der Hoeven]

> > But: did you really experience these problems when gluing Qt and
> > TeXmacs?
> 
> Yes, because I am currently in the incomfortable position to use
> X both thru Qt and directly. Including the X headers after the Qt ones
> make so that the X #defines don't alter the Qt headers.

OK, but did you experience problems with the *TeXmacs* macros?

> This talk about name collisions leads me to a long term remark. When
> TeXmacs will be usable as a library it will have to export an API in C
> and C++.  In C, for lack of better scheme, the current usage is to use
> macro to prefix exported names with a unique string.  In C++, each
> library must lie in its own namespace.

Yes, I indeed aim to provide C interfaces (as is already the case
for TeXmacs.h) and you are right about the prefix convention.
The TeXmacs prefix will be "tm_". I do not think that the API's for
TeXmacs will contain many macros though.

> > > I see no reason to shy away from enums. They group related consts
> > > which is a good thing. There is no reason to ask oneself metaphysical
> > > question about the type difference between bitmasks and "true"
> > > enumerations. The C++ language has no support for such differentations
> > > anyway so that is a moot point.
> > >
> > > Really, I did not expected to have to argue about a so minor patch.
> > 
> > I see two good reasons for not applying the patch:
> >   * The current code works fine so why touch it?
> >   * The metaphysical reason that we mentioned.
> > You should not underestimate the first point.
> 
> When adding booleans, I have noticed that introducing stronger typing
> stress your code and indeed uncover inconsistencies. I think this is a
> good thing on experimental version (but not prior a stable release).
> The mantra is early detection of problems and strong typing helps.

Yes, but I can only handle a very limited number of such bugs at
the same time. I remind you that I fix 95% of the bugs in TeXmacs
and I do not want to spend 25% of my time on this.

> > Your patch which imposed the bool type introduced a very subtle bug
> > caused by type overloading. It took me half a day to eliminate it.
> > It also took me half a day to carefully apply the patch,
> > thereby avoiding some other subtle bugs of the same kind.
> 
> My bad if I forgot to send such a correction of
> a problem triggered by my enums patches. I would happy to learn
> what it was to be able to recognize it if it happens again.

The point is that such problems would have been very hard
to detect for you, because some of them are related to
using special features of TeXmacs.

My general strategy is to avoid bugs *a priori* as much as possible,
by making changes in a very careful way. This does not apply so much
to changes which affect a single file or even a single routine,
but it does apply to global changes which affect many files.

> > We *are* going to do this next year. Remember that the focus for
> > version 1.0 was on having a useable and (almost) fully featured
> > wysiwyg structured text editor. The focus for version 1.1
> > is on stabilization, which means:
> >   * More standard DTD's (style files; more or less done)
> >   * More standard User interface (done)
> >   * Better converters with standard formats (in progress)
> >   * Better documentation (in progress)
> >   * A clean scheme interface (coming up)
> >   * Clean rewriters for XML (coming up)
> >   * Modularization of the GUI (->Qt) (coming up)
> >   * Higher portability (coming up)
> >   * Etc.
> > But we *do* need time!
> 
> I agree. I like to experiment widely and wildly to accumulate
> experience and to share it. That does not mean that everything I
> say is correct or need to be applied immediately. And when possible
> stuff that can be #ifdef'ed must be included ass soon as possible.

Right, so that is why I would like to postpone the enum stuff.
I am not vicerally against it, but I think that there are more
important things to be done at the moment. In any case,
I kept it apart, so I can always take a look again;
this patch does not necessitate much syncing.

> Also testing code with different allocators and/or GC scheme is
> a good way to detect problems  that may not lie elsewhere.

I agree with this opinion. In fact, my plan is to remove
the global allocater and make it a member function of
a base class to all TeXmacs classes. Later on, I want to
provide an option for using Boehme's GC.

> My general point is that breaking code is sometimes good.  It is
> probably bad to let you indentify and debug such uncovered problems,
> so let us know.

Yes, breaking code is even a *necessary* thing to do every once and
a while. However, one has to be very careful when replacing it;
doing this in an incremental way with many safeguards is the best
strategy. My experience is that a silly bug can take more time to
be debugged than taking one day making *sure* that bugs of a certain
type can not happen (by putting explicit tests in the code).