Setting a direction

[Ludovic Courtès]

Hi Andreas,

Andreas Rottmann <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:
>>
>> Personally, I'd be glad if Andreas could provide use his views on the
>> topic.  I'd like to see more consistency and clear rationale in the
>> changes that we make, and I'd like them to follow *some* vision of what
>> G-Wrap should be.  In particular, clarify whether G-Wrap is just
>> guile-gnome's and Gnumeric's tool (I say "just", but I know it's already
>> a lot), or whether it's trying to be a generic replacement for SWIG, at
>> least for Guile-targeting programs.  I'm hoping for the latter, and I
>> believe that's how it started.
>>
> Well, Wingo's generic method changes are not only benefitting
> guile-gnome, but all clients that want to use this feature - they're
> not really "application-specific". I hence see no reason not to apply
> the changesets.

Right.  I perfectly agree (about merging the latent binding patches) now
that Wingo has given pointers to posts describing the problems that
those changes solve.

I was actually referring to bits like this:

>> #    * guile/g-wrap/guile.scm (module-public-interface): Make sure that
>> #    using (g-wrap guile) also uses (g-wrap c-codegen), as it used to.
>> #    This fixes compilation of guile-gnome.

I don't think arguments like "this fixes compilation of FOO" are
sufficient to drive G-Wrap's development, as we've already discussed.
Thus, I would be tempted to reject such changes.

The counterpart to being this firm is that I would try to:

  1. Clearly document such changes in G-Wrap so that users like
     guile-gnome developers don't get stuck.

  2. Document as best as we can G-Wrap's API (which I started to do
     several months ago) so that users know what they can rely on.

  3. Make principled choices _now_ when designing the API so that we
     don't feel the need to change it a few weeks/months later, and, in
     any case, do not change the API within any major release branch
     (e.g., 2.x).

These seem reasonable goals and I'd be happy to help further with it.
But if we decide to go for such a plan, then we must stick to it and
avoid making ad hoc changes.

If one of the current G-Wrap users has unsatisfied needs, then we should
reason about them and try to see how they can be solved in a generic way
that may be beneficial to _all_ users.

> And regarding G-Wrap as a generic SWIG replacement,
> I'd say no, since it's unlikely that G-Wrap will support other
> languages then Guile (despite the half-finished s48 support).

Sure.  I actually mentioned "a generic replacement for SWIG, at least
for Guile-targeting programs".  I think a reasonable goal for the 2.x
branch would be to produce a usable, well-documented, and more powerful
alternative to SWIG for Guile users.

Would you agree?

Thanks,
Ludovic.