On Sun, Feb 10, 2008 at 08:18:05AM +0000, Lalo Martins wrote:
> 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.)

This is a result of the design decision to have the interfaces be 
reflectively described using VOS.  Since the API is described using 
Vobjects, and the vobjects must be located on a unique site, references 
to vobjects must include site identifiers.

It's worth pointing out that XOD is extremely low level and not really 
intended as the primary way of editing vobjects, but it is all we've got 
at the moment.  I am thinking about writing some tools that will take 
care of some of the house cleaning task like fixing paths and assigning 
identifiers to individual vobjects in order to transform a partially 
specified file into a fully specified one.

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

Actually it is the other way around.  The bug is that the type attribute 
does *not* presently require a site id, due to a quirk (well really a 
hack) in the way it uses the type attribute string to look up which 
component implementation to use.  It ought to require the site id so 
that it unambigiously refers to a specific vobject class type.

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

I will have the code generator insert comments into the files so you 
know the difference.

> Each Namespace "world" gets a "world.hh" with wrappers and interfaces, 
> plus "worldComponents.hh" and "worldComponents.cc" 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.

As you said, "x.hh" gives you the interfaces, "xComponent.hh" gives you 
the implementations.

> And each Class or Lambda "foo" gets its own "foo.hh" and "foo.cc", 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.)

One way to manage this would be to put in comment guards that indicate a 
certain section of the file is replaceable, and update that section for 
API changes.

> 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"?)

The code generator should probably tack on something to the file name so 
you get HelloWorldLibrary.cc, HelloWorldNamespace.cc and HelloWorld.cc.

[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