Hi, > > Just to clarify on my approach. The XSBuilder class parses out alot of > data from the header file. This data is output currently as a Data::Dumper > string to something referred to as a PPD file. > > Currently I just using that output, and that only as to drive the POD > generation. If the PPD doesn't have it, then I'll have to modify my > approach. >
Do you use an extra program to do this or is your code inside of WrapXS.pm? > > I interpret that as if the class is a package, then we treat the C > function as an object method, otherwise we treat it as a Perl function. > Yes (if you mean the class of the first argument) > > Now if we make the first C argument an object, what do we do with the > documentation for it. Putting in along side the method parameters > as just another "=item" seems confusing. Do we create a new breakout? > I like the idea of writing @object instead of @param > The question of how to differentiate any C return value is similar. > return doesn't have a name (like Stas already pointed out) > > I think you should just list all the arguments as arguments, and when we > > manually cleanup the autogenerated pages, we will fix those things. > > What's important is to save on writing descriptions (correctly). > > Reshuffling things is not a problem. We will have to scrutinize all the > > generated docs in any case. This cleanup process should give as much possible feedback to the programm writers, so we can learn from this cleanup process and hopefully automate some more things. > > Understood. When you discussed generating the documentation in stages, > I wasn't sure whether the output of this current stage would feed into > more automated phases (in which case, you'd be more concerned about > preserving context), or all remaining phases would be manual (in which > case, a human can deduce the context so it becomes less of an issue.) > The one you generating at the moment should be machine readable, so it gives us the posibility to use it for other purposes as necessary. Gerald ------------------------------------------------------------- Gerald Richter ecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131 WWW: http://www.ecos.de Fax: +49 6133 925152 ------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
