Also spracht Reed Hedges (Sat, 09 Feb 2008 10:35:25 -0500):
> The new type IDs are still bothering me a bit too (among other things,
> like the code namespaces).  A huge advantage of the old user-invented
> type names is that they were natural to understand and easy to remember.
>    We're going to have to do a lot of cutting and pasting, and when we
> get one digit wrong, will be tearing our hair out over it.  (Or the only
> option will be to use the GUI tool.)

AIUI from IRC conversations, the site IDs won't actually be visible to 
the application programmer later on; we'll deal only with IDs like "/vos/
core/StringProperty".  (I'm not sure about the code namespaces, but I 
hope some simplification is intended there too ;-) )  Peter has actually 
told me a few days ago that side IDs being required for the type 
attribute in XOD is "a bug".  For now, we cope; the IDs are extra work, 
but not really a killer.

> Also, what in the HelloWorld example is autogenerated and what isn't?

All C++ files except for (and in my branch, are 
generated.  Here's how I observed it works:

Things are packed in Library and Namespace objects.  Inside a namespace, 
you'll usually have classes (Class) and functions (Lambda).

Each Library "hello" gets a "", responsible for registration 
of all interfaces/components in the Library.

Each Namespace "world" gets a "world.hh" with wrappers and interfaces, 
plus "worldComponents.hh" and "" with components.  It's 
not yet 100% clear to me when "user" code should #include "x.hh" or 
"xComponents.hh"; I believe if you need to create a new instance of 
something, you need "xComponents.hh", otherwise "x.hh" will allow you to 
work with existing objects.  Each "xComponents.hh" already #includes 
"x.hh", so you never need both.

And each Class or Lambda "foo" gets its own "foo.hh" and "", where 
you'd put the concrete implementation.  These don't get overwritten if 
they exist, since they will contain handwritten code.  (Which makes it a 
bit of work to cope with API evolution, but you can always point the 
generator at a new, empty directory, then copy-paste.)

This naming pattern unfortunately means you can't have two 
"things" (class, function, namespace) on the same directory.  Whether 
that can be a problem is illustrated by helloworld itself: if you write a 
"Library" to contain only one single class, the most natural naming would 
be for Library, Namespace and Class to have the same name.  Suggestions 
on how to fix this are appreciated, I have no idea myself ;-)  (Maybe 
something like "/helloworld/core/HelloWorld"?)

                                               Lalo Martins
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
GNU: never give up freedom    

vos-d mailing list

Reply via email to