From: Marcelo M. <mm...@ac...> - 2005-12-13 18:51:16
|
Williams, Gerald S (Jerry) wrote: >Marcelo Matus wrote: > =20 > >>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). >> =20 >> > >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.=20 > oh yes, it was taking in consideration, and overweighted with the=20 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 fo= r 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=20 do it: 1.- we needed to simplify, reduce and reuse the typemaps we have in the=20 library, since while is "simple" to maintain the C types (int, double, float, etc) for one=20 language, the things get crazy when you add more languages and C++ classes and templates, ie, think about=20 this one: std::vector<std::pair<int, double> > *INPUT which now is recognized automatically by typemap.i (python at least,=20 while we keep moving forward). we also need consistence and proper implementation across languages and=20 for once, since even today we get reports that for a language (ruby,tcl,perl..) a=20 'signed char' (or so)=20 typemap (in,out,varin,varout,directorin,directorout,memberin,typecheck, freearg, INPUT, OUTPUT, INOUT,etc.etc... you pick one) was not working=20 as expected. there were just too many many typemaps to keep working properly and in=20 a "readable" way at the same time. 2.- you have notice that even when is harder to read for human, the=20 typemap.i implements the same typemaps (and much more) than before, and all the=20 test-suite and backward compatibility tests work.. ie, the interface is exactly the=20 same, only the implementation is different. 3.- while it would be ideal you can just read the typemap.i library and=20 learn from it, we end in the same situation you have with the C++ STD/STL libraries,=20 i.e., nobody try to learn how to write a template from reading the files <vector>,=20 <list>, etc. or how to write a header file from reading just a "simple" thing as=20 <math.h>. but the good thing is that the solution is easy, as I said, we can leave=20 the old code in the typemaps file for reference for the users, while swig uses the new=20 implementation. > I'm sure the extra > macro overhead probably slows builds as well. well, now swig is probably faster than before in many cases, since Willia= m also was concerned about that and we take care of it by profiling and tun= ing swig around. >>Also, with the new Unified Typemap Library, I hope we can document >>and make public some of its internal functions/macros, and then >>reduce the unexpected ways users are now using swig. >> =20 >> > >Yes, I hope so, too. But keep in mind also that the only truly >reliable documentation is the source code itself, so it would >be best to keep that as understandable as possible. > > =20 > and we always try to do that, don't worry. Marcelo >gsw > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=FFick >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > =20 > |