On Mon, Mar 17, 2008 at 07:33:24PM +0000, Lalo Martins wrote: > Well. I spun off the web MVC stuff into a new library (hypervos). That > opened a pandora box of generator fun :-)
Yea, as you've probably figured out by now, writing good C++ is hard, but automatically generating good C++ is even harder. > Also, I'm not saying these need to be fixed urgently; just that we need > to know about them for the future. I'm not surprised by any of these limitations you ran in to, I've been planning on fixing them when it became a real problem. > 1: mod_vos.xod (and my other projects) extend a lot of classes from the > new library. But since the generator doesn't know about those, it > reports broken links and generally doesn't know what to do. > > The answer to this may be in my plugin loader; I might try my hand at > solving it later this week. At the moment, external libraries can successfully import from the main VOS namespace because it is available in the generator by virtue of being compiled into libvos. However, it should be able to import from other libraries in general. A stopgap solution would be to add an option to the to generator pre-load additional XOD files. Eventually we should have a general set of strategies for searching for site replicas (local repositories, going on line, possibly extracting them from executables) so finding and importing an interface library will be no different from accessing and replicating any other vobject site (be it a 3d world, hypervos, etc). I do like the idea of using the plugin loader to ask a binary library what its interface is. > 2: The #define guards use only the file name. If you have headers with > the same name in different libraries (eg MVC.hh)... you get my point I > think. I manually changed them to eg #define _hypervos_MVC_hh_, might > make the change in the generator later. Oops. Yes, the generator should be smarter than that. See my comment below about directory organization for headers. > 3: Much worse happens if you have namespaces with the same name :-) the > generated code has things like MVC::View all over, which of course > generate "ambiguous namespace reference" errors galore. This is a bit of a pathalogical case, although hopefully now you see the reason for the site_xxx namespace. The brute force solution would be to have the generator go ahead and qualify everything with the excessively long site_xxx namespace, which I was trying to avoid purely for the sake of readability. > 4: This is unrelated to the hypervos move, I noticed it earlier. If my > class "Foo" extends "vos::core::Bar", then Foo.hh will have > #include "Bar.hh" > which of course won't work so well... should be <vos/Bar.hh> :-) Since I was originally focused on getting the libvos core to work, I didn't give too much thought to how the C++ headers should be explictly organized into directories. Again, the brute force solution would be to have the headers mimic the namespace up to and including the site, which would be horribly verbose but would eliminate most of the ambigious cases. > 5: Just to put in a positive note and because I like the number 5 better > than 4, I'll say I found great joy in recent s5 work; in particular > Vobject::clone() saved me hours of toil! That's good to hear :-) I slipped that one in as part of the template stuff I did (which you should take a look at, by the way.) -- [ Peter Amstutz ][ [EMAIL PROTECTED] [EMAIL PROTECTED] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
