Quoting Gerald Richter ([EMAIL PROTECTED]): > > > > > Mainly it's ok. A few things are different: > > > > > > - The apr_ prefix gets striped in the Perl interface
That's good to know, because I don't think currently the Perl interface name is generated directly. > > > > so does ap_, and sometimes its even more when the PACKAGE=guess, see how > > apr_get_remote_host() becomes remote_host(). Gerald, I think it's not > > enough to parse docs. You must really apply the same heuristics you > > apply for creating the XS code in WrapXS, otherwise what's the point of > > using WrapXS in first place for parsing docs? The logic shouldn't be > > duplicated. If you get the XS right, the docs should get it right too! > > > > Yes of course. That's excatly what we do, but WrapXS gives so much > informations and Lyle is about to figure out which are the correct one to > use. So I should have said more clearly: The prefix has to be striped, i.e. > use the Perl name that WrapXS provides not the C name. 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. > > > > - These are method calls > > > > > > Stas, in the AUTOGENERATION documents the example shows a function, but > I > > > think in this case we have methods. What do you think? > > > > I don't know how to handle these generically, since some functions > > become methods in perl others don't. Do we have any solid heuristics for > > figuring that out? > > > > The simplest heuristics to start with would be to check whether the > > first argument is request_rec, connection_rec, apr_pool_t, etc and turn > > these into methods. The rest keep as functions. > > > > I think basicly we should look at the first argument, if it's an object we > write it as method, otherwise it will become a function. We may add some > hints to the map files in case that becomes necessary. 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. I've seen method call examples. Can you give me a function call example. Examples always help. :-) > > > > > >>=head2 @func: apr_table_set() > > >> > > >> apr_table_set($t, $key, $val) > > >> > > > > > > > > > # write as > > > > > > $t -> table_set ($key, $val) > > > > yes, but no spaces please. > > Sorry, I always prefer spaces in my code, but of course the output should > conform to the style of the rest of the mod_perl docs. > > > This is not how we write docs, should be: > > > > $t->table_set($key, $val); > > 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? The question of how to differentiate any C return value is similar. > > notice ';' > > > > [...] > > > > >>=item @return: > > >> > > >> copy of the table passed in > > ^^^ > > make sure to strip all leading spaces, e.g. in the above case. Since > > otherwise it won't be rendered as text. Ok. I think the data is already stripped, so I just need to make sure I don't add any back in as I output it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
