gmane.comp.lib.vos.devel

Lalo Martins | 17 Mar 20:31

Fun with the generator

Well.  I spun off the web MVC stuff into a new library (hypervos).  That 
opened a pandora box of generator fun 

I'm a bit exhausted, so I'll go over them briefly; if you need more 
detail, ask, and I'll elaborate tomorrow.  Or check out my branch and 
play around yourself.

Also, I'm not saying these need to be fixed urgently; just that we need 
to know about them for the future.

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.

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.

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.

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>

(Continue reading)

headers

Lalo Martins | 18 Mar 14:19

Re: Fun with the generator

Also spracht Lalo Martins (Mon, 17 Mar 2008 19:33:24 +0000):
> 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.
> 
> 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.
> 
> 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.
> 
> 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> 
> 
> 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!

Fixed 2 and 4 today, may tackle 1 or 3 tomorrow.

best,
                                               Lalo Martins

(Continue reading)

headers

Peter Amstutz | 18 Mar 16:09

Re: Fun with the generator

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

(Continue reading)

headers

Lalo Martins | 19 Mar 01:00

Re: Fun with the generator

Also spracht Peter Amstutz (Tue, 18 Mar 2008 11:09:24 -0400):
> 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.

:-D

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

Fixed in my branch (assuming we agree _hypervos_MVC_hh_ is good enough).

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

(Continue reading)