I'm worried about introducing yet more complexity into S5. You know that this is
a big concern of mine.
What is the exact overhead for having entries in the child list for embedded
properties? You need a contextual name, and you need the object. The list
itself stores the position value. The
On Thu, Apr 24, 2008 at 11:39:01AM -0400, Reed Hedges wrote:
>
> Properties as child vobjects is too useful to get rid of I think. If
> properties are always embedded, then you can't have two vobjects share
> a property, which is one of the most important features of VOS. They
> also can't be
In other words, I sort of imagined it like this:
class Entity
{
handleMessage();
set parents;
string url;
}
class Link
{
string cname;
int pos;
Entity *child;
Entity *parent;
}
class Vobject : Entity
{
list children;
vector embeddedProperties;
list components;
etc.
}
Properties as child vobjects is too useful to get rid of I think. If
properties are always embedded, then you can't have two vobjects share a
property, which is one of the most important features of VOS. They also can't
be remote for whatever reason, and you can't use the normal
Vobject/Metaobj
Things have been quiet lately, but I assure you, we are still working!
Anyway, something I've been mulling over --
One of the planned changes in the design of s5 as compared to s4 is the
integration of plain-old-data properties as part of the vobject class
definition. In s3 and s4, property da
