Re: Official .defs files

[Karl Nelson <kenelson flounder ece ucdavis edu>]

> > Certainly it should be considered.  I just don't think it should
> > be a show stopper.  The defs file already involves merging information
> > which can't be known by simple extraction.  Conditional compiling
> > enums certainly fit this bill.
> > 
> > (There are things which should be avoided like...
> > 
> > enum {
> >    ENUM1,
> > #ifdef SOMETHING
> >    ENUM2,
> > #endif
> >    ENUM3
> > }
> > 
> > Because it causes unnecessary binary problems and will be a total
> > pain in the ass to extract.)
> 
> But again, if the point is to develop a standard that will work across
> many C-APIs, even internal APIs for projects that just want to use
> this tool to wrap their own API for internal consumption (by Guile for
> example) and where this kind of conditional enumeration is just fine,
> then you don't have control over whether or not the C APIs do this
> sort of thing, and this (ignoring the compilation time issue) isn't
> hard to accomodate at compile time AFAICT.

Do you agree the above example is bad practice?  Depending on the
definition of SOMETHING, ENUM3 can have a value of 2 or 3, and thus
binaries compiled with this would behave differently.  Switch 
statements would be thrown into undefined states.  If one library
on the system had SOMETHING set and another library on the same
system didn't it would result in a wealth of hard to detect errors.

Moreover, it doesn't matter if we had numerical values in
the defs file, as it would still have ENUM2 in there.  Thus 
the binding wrappers would generate a place for ENUM2 which
may or may not exist.  Thus the defs file would be best not
to contain this enum definition at all.

That construct really is completely beyond the scope of 
coding which a defs file could contain.   Just because 
a language allows a construct does not make it a good idea.  
Just see C++ for a gross number of examples.  ;-)

 
> However, if the .defs files are only intended for wrapping GNOME/GTK
> stuff, and/or for APIs which are willing to follow some rules (in
> which the above construct would be no-no), then you're right.

I would say for what I am concerned with (and the point of the
GNOME language bindings list), the defs format are intended for 
wrapping GLIB/GTK/GNOME and other APIs which are reasonable 
conforming to them.  I don't think an automatic extraction to defs tool 
should have to handle every conceivable case.  Keeping things uniform is 
good in that it allows for simpler bindings.  If that means coding must be
restricted to follow the gtk+ coding and naming conventions, than
that is best for both the users (who want to use a consistent object model)
and the binding writers (who don't want to have to wrap 10 different 
object models.)

If it could handle things which break conventions, it would be a bad thing
because then it would mean that the GNOME libraries would contain 
subsections which are grossly inconsistent with the model presented
by the rest of the system.  If the defs extractor warns that 
something breaks a gtk+ coding convention I would consider it a feature
and not a bug.  

  
> It just seems like a somewhat fragile assumption to me.

If you want to make defs more than GLIB using libs than please 
go ahead.   Though if that cuts out of its primary mission of wrapping
GTK/GNOME, that would be a very bad thing.

--Karl