<br><font size=2 face="sans-serif">Arriving late to this discussion. Why
is a single super class not the answer here? llEntity contains the information
which is true of all elements, then derived classes differentiate based
upon usage? One, large, monolithic class makes things easy in the short-term,
but harder over time and totally defeats the design goals of an object
oriented system. IMHO :-)</font>
<br><font size=2 face="sans-serif"><br>
Best regards<br>
Alan<br>
-------------------<br>
T.J. Watson Research Center, Hawthorne, NY<br>
1-914-784-7286<br>
alan_webb@us.ibm.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Melanie <melanie@t-data.com></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">opensim-dev@lists.berlios.de</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">11/10/2008 10:07 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Opensim-dev] Should SOG and SOP
be combined into a single        object in
a linked hierarchy?</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Yes. That is one of the main points. I think I can
bring <br>
hierarchical linking even to the LL viewer with that concept of just <br>
one object type.<br>
<br>
Melanie<br>
<br>
<br>
Dahlia Trimble wrote:<br>
> Would this proposal allow linksets to be children of other linksets?<br>
> (assuming we would ever want that)<br>
> <br>
> On Mon, Nov 10, 2008 at 8:08 AM, Justin Clark-Casey <<br>
> jjustincc@googlemail.com> wrote:<br>
> <br>
>> Somewhat separately from Adam's other post, I'd like to raise
this issue on<br>
>> the mailing list since it keeps popping up.<br>
>>   I'll confess that I'm not 100% convinced yet that SOG and
SOP should<br>
>> simply be combined, though I do accept that the<br>
>> code does need some architectural changes.  Unfortunately,
I'm not quite up<br>
>> to drawing diagrams yet.<br>
>><br>
>> This discussion may also have come up on the mailing list in some
way<br>
>> before so references are welcome, as are<br>
>> clarifications to the statements below.<br>
>><br>
>> Melanie's proposal, as I understand it, is to combine the current
SOG and<br>
>> SOP into a single object (let's call it<br>
>> LLEntity).  LLEntity's would be linked into a tree, so there
can be<br>
>> something like<br>
>><br>
>><br>
>>            LLEntity<br>
>>           /    |   \<br>
>>          /     |    \<br>
>>         /      |    
\<br>
>>        /       |    
 \<br>
>> LLEntity   LLEntity    LLEntity<br>
>>                |<br>
>>                |<br>
>>            LLEntity<br>
>><br>
>><br>
>><br>
>> Here are some of the pros and cons as I see them.  Adam has
already talked<br>
>> about some of these in his blog post.<br>
>><br>
>> Pros<br>
>><br>
>> 1.  At the moment we can only have one level of prim linking
(as<br>
>> effectively dictated by the LL Second Life client).<br>
>> Linking into a tree would allow multiple levels of linking (though
with the<br>
>> assumption of single parents).<br>
>><br>
>> 2.  It makes manipulation of prims much easier.  Instead
of having to<br>
>> reference SOPs in and out of SOG, everything is<br>
>> done on a single class.  Some properties can be set on a
SOP reference<br>
>> without having to worry about whether they are a<br>
>> root SOP or not (see below).<br>
>><br>
>> 3.  The Second Life client protocol wants to manipulate SOPs
directly in<br>
>> many situations (e.g. individual prim selection<br>
>> of a group, the fact that local ids are passed around that reference
prims<br>
>> rather than linksets).<br>
>><br>
>> 4.  Get rid of the root part checks on object deletion.  However,
a lot of<br>
>> these come from the fact that we null out<br>
>> m_rootPart after object deletion when there may be no need to
- I'm<br>
>> anticipating that extraneous info sent to a viewer<br>
>> about a deleted object will be simply ignored.  This is a
change we should<br>
>> try soon now that we're at the start of a<br>
>> release process.<br>
>><br>
>><br>
>> Cons<br>
>><br>
>> 1.  LLEntity becomes very large and potentially complex.
 SOG and SOP are<br>
>> already large and complex.  It may be possible<br>
>> to improve this by further refactoring.<br>
>><br>
>> 2.  Every setting and getting of a property in LLEntity has
to delegate up<br>
>> to its root LLEntity unless it is the root.<br>
>> Therefore, code such as<br>
>><br>
>>         public virtual Vector3 Velocity<br>
>>         {<br>
>>             get { return m_velocity;
}<br>
>>             set { m_velocity = value;
}<br>
>>         }<br>
>><br>
>> becomes something like<br>
>><br>
>>         public virtual Vector3 Velocity<br>
>>         {<br>
>>             get<br>
>>             {<br>
>>                 if (ParentEntity
!= null)<br>
>>                  
  return ParentEntity.Velocity;<br>
>>                 else<br>
>>                  
  return m_velocity;<br>
>>             }<br>
>><br>
>>             set<br>
>>             {<br>
>>                 if (ParentEntity
!= null)<br>
>>                  
 ParentEntity.Velocity = value;<br>
>>                 else<br>
>>                  
 m_velocity = value;<br>
>>             }<br>
>>         }<br>
>><br>
>> One also needs to be careful to set the publicly available property
so that<br>
>> delegation happens if required, rather than<br>
>> the private field to avoid state such as 'attached' becoming inconsistent<br>
>> (this is a potential source of bugs).<br>
>><br>
>> 3.  It leads to an increase in property duplication at the
database and<br>
>> serialization levels.  Every LLEntity will have<br>
>> a set of fields, even though some of those conceptually only apply
to a<br>
>> linkset/SceneObjectGroup.  This probably isn't<br>
>> serious but I think that it will make things harder to work with
at those<br>
>> levels.<br>
>><br>
>><br>
>> This isn't a full set of pros and cons, just the ones that occur
to me<br>
>> right now.  I'm sorry this is a long post but I<br>
>> feel that we need to a get a long form view of this as change
here will<br>
>> stay with us for a considerable time into the<br>
>> future.  If there isn't any major discussion then this may
go ahead anyway<br>
>> (since Melanie, for one, is quite keen and I<br>
>> may be the only person really bothered about this).<br>
>><br>
>> At the moment I'm actually leaning towards the single LLEntity
suggestion,<br>
>> though I'm a little concerned about the<br>
>> duplication that ends up at the database/serialization level.
 But I'd<br>
>> really like to hear what other people think.<br>
>><br>
>> --<br>
>> justincc<br>
>> Justin Clark-Casey<br>
>> </font></tt><a href=http://justincc.wordpress.com/><tt><font size=2>http://justincc.wordpress.com</font></tt></a><tt><font size=2><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> Opensim-dev@lists.berlios.de<br>
>> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
>><br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> Opensim-dev@lists.berlios.de<br>
> </font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
</font></tt><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"><tt><font size=2>https://lists.berlios.de/mailman/listinfo/opensim-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>