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.)

[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 ]

Attachment: signature.asc
Description: Digital signature

vos-d mailing list

Reply via email to