Re: [Swig-devel] The swig hate webpage

[William S F. <ws...@fu...>]

Marcelo Matus wrote:
> Williams, Gerald S (Jerry) wrote:
> 
>> Marcelo Matus wrote:
>>  
>>
>>> well, I hope with the new Unified Typemap Library, at least at the
>>> typemap side, the things get much more stable and consistent between
>>> languages (perl, python, tcl and ruby at least).
>>>   
>>
>> Interesting you should mention that. When I needed to write a
>> typemap or wanted to show someone an example of how to do it,
>> I'd usually go to typemaps.i. That way I'd also pick up on
>> any SWIG function changes. But when I tried to do it recently,
>> I found that they'd been completely reorganized so that common
>> implementations were shared. Unfortunately, the complex macros
>> that resulted are unusable by mere mortals. This to me is an
>> example of what the detractors are complaining about. It's the
>> right thing to do, but the value of typemaps.i to users as a
>> reference wasn't taken into consideration.
> oh yes, it was taking in consideration, and overweighted with the 
> benefits of
> the unified typemap library across the languages, as usual we do.
> 
> but well, since this is the second reference to missing the typemaps.i for
> reference reasons, we will leave the old typemaps code there, disabled
> but readable.
> 
> and since we get in to the point, here  are the arguments why we need to 
> do it:
> 
> 1.- we needed to simplify, reduce and reuse  the typemaps we have in the 
> library, since while
> is "simple" to maintain the C types (int, double, float, etc) for one 
> language, the things get crazy when
> you add more languages and C++ classes and templates, ie, think about 
> this one:
> 
>      std::vector<std::pair<int, double> >  *INPUT
> 
> which now is recognized automatically by typemap.i (python at least, 
> while we keep
> moving forward).
> 
> we also need consistence and proper implementation across languages and 
> for once,
> since even today we get reports that for a language (ruby,tcl,perl..) a 
> 'signed char' (or so) typemap 
> (in,out,varin,varout,directorin,directorout,memberin,typecheck,
> freearg, INPUT, OUTPUT, INOUT,etc.etc... you pick one)  was not working 
> as expected.
> 
> there were just too many many typemaps to keep working properly and  in 
> a "readable" way
> at the same time.
> 
> 2.- you have notice that even when is harder to read for human, the 
> typemap.i
> implements the same typemaps (and much more) than before, and all the 
> test-suite
> and backward compatibility tests work.. ie, the interface is exactly the 
> same, only
> the implementation is different.
> 
> 3.- while it would be ideal you can just read the typemap.i library and 
> learn from it,
> we end in the same situation you have with the C++ STD/STL libraries, 
> i.e., nobody
> try to learn how to write a template from reading the  files <vector>, 
> <list>, etc.
> or how to write a header file from reading just a "simple" thing as 
> <math.h>.
> 
> 
> but the good thing is that the solution is easy, as I said, we can leave 
> the old code in the
> typemaps file for reference for the users, while swig uses the new 
> implementation.
>

The typemaps in typemaps.i are just one set of typemaps which are a 
useful reference. How about the following instead. As the interface 
files in the Lib directory are getting quite complicated and hard to 
follow, why don't we use them as source files to generate more human 
readable versions. That is we move all the files into a separate source 
tree and run them all through the preprocessor (swig -E) to generate the 
human readable versions that people can learn from and understand. The 
generated files will form the  current Lib directory structure and will 
be installed on the users machine and be the real library files. That 
way a user can easily read them and even take a copy of them as the 
basis for their own typemaps.

Can anyone see any problems with this approach?

William