[vos-d] More new S5 classes/concepts

[Reed Hedges]

I've updated http://interreality.org/wiki/S5 with this information. 
Peter, can you please check it and fix it if anything is inaccurate?  I 
did elide some of the minor details, just in the interest of clarity.

Some minor comments below about naming things to be less confusing to 
think about if you want...

Also it might help people understand how VOS works if the libvos code 
was seperated a bit into directories or the files were named according 
to use 'layers'...  E.g. I don't think people need to the code 
generation infrastructure much?


>>    ConstructorFunctionWrapper
>>    ConstructonFunctionFunctor
>>    ConstructorFunctionComponent
> 

rename ConstructorFunction* to Constructor*? Are there other 
ConstructorThings?


>>    The host's factory (i.e. from Host::getFactory())
> 
> In order to create new objects attached to a particular Site, you use 
> the Factory object on that site (Hosts are a special type of Site.)  
> This is the basically the same as s4 with Site::createVobject(), but 
> separating the Factory out to a distinct Vobject.
> 

Would it make sense to hide all this 
(Factory/Constructor/Implementation) with a few more convenient static 
methods in Host, at least to address the most common needs of creating 
vobjects.   (While users who need to do more advanced things like add 
new types etc. can access the factory.)   We ended up doing something 
similar in S3/S4 I think?


>>    DataTypeWrapper
>> ParentChildLinkWrapper
 >> ClassWrapper

etc.

I still think it would be easier for people to use VOS if the wrapper 
classes had "plain" names, and the thing being wrapped had the funny 
name.  E.g.

DataType is the wrapper for DataTypeCore or DataTypeImp or DataTypeBase.

Or DataType is a subclass of DataTypeBase which overloads DataTypeBase 
to add the Wrapper stuff? (Maybe it also inherits from a Wrapper base 
class?)

I.e. it seems to me that at the most basic, and starting/newbie "use 
level" users just need to work with wrappers. Through the vobject 
wrappers they find children, access component wrappers, etc.  So this 
"use level" should be the simplest and hide some of the complexity 
that's going on.

The second "use level" is defining new types, primarily component types.

And then, beyond that, users would maybe need to deal with Interface and 
Implementation objects.   I.e. maybe adding support for a new language 
or something?   Or ever?

...

>> What does it mean to append children to the local host?  I am guessing 
>> this is so the object doesn't get destroyed (by reference count/garbage 
>> collection), and so you can also obtain it by name later?  Do all 
> 
> The local host is a special site.  Sites now have a root child list 
> which is like a root directory.
> 
>> objects need to be added to the local host (like they were all children
>> of the local site in s4)? And if so, why not do that automatically when 
>> created?
> 
> When created, vobjects must be associated with some site (such as the 
> local host).  The intention is that in order for the vobject to be 
> persistant, it must be connected to the vobject structure so there is a 
> path from the root to the vobject.  Vobjects which are not connected to 
> the root are not persistent.
> 

So a factory that you obtain with Host::getFactory() is not associated 
with the local host really?

Could we integrate the adding of a Vobject to the local host into the 
creation of a vobject (as above wrt. factory).

I.e. I'd like creation of Vobjects on the fly to be easier... it really 
should be even easier than in S4, which is  sort of complex and hard to 
remember what function to use when...

Reed