[Opensim-dev] Should SOG and SOP be combined into a single object in a linked hierarchy?

[Ryan McDougall]

That may not remain the case forever.

I think Adam's point is that people want to innovate, and that may
cause models that diverge/evolve over time, and that is preferred to
deciding OS isn't flexible enough and abandoning it.

Cheers,

On Wed, Nov 12, 2008 at 12:03 AM, Melanie <melanie at t-data.com> wrote:
> Rex is upward compatible to SL. SL viewers can't render the objects.
> In that sense, rex extends LLEntity. Therefore, it can inherit from
> it. Problem solved.
>
> Melanie
>
>
> Frisby, Adam wrote:
>> The only possible concern I have with linking in part is when the systems may be compatible enough to enable it maybe it's worth broaching.
>>
>> Croquet and SL isn't compatible, but Rex and SL might be. Or Rex and Multiverse.
>>
>> Adam
>>
>>> -----Original Message-----
>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>> Sent: Tuesday, 11 November 2008 9:46 AM
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] Should SOG and SOP be combined into a single
>>> object in a linked hierarchy?
>>>
>>> No objection to making embedded classes and helpers. Just as long as
>>> those are created at construction time of the main class and never
>>> removed until the LLObject itself is disposed. So we can assume
>>> references are never null and get those null checks out of the code.
>>>
>>> As for linking, I think each object type should like with itself
>>> only. So each object type should implement it's way of linking. If
>>> that needs to be extended, it can be extended without ramifications
>>> to objects for other applications, which may not even be known to
>>> everyone. Like breaking non-core applications...
>>>
>>> Melanie
>>>
>>>
>>> Sean Dague wrote:
>>> > Justin Clark-Casey wrote:
>>> >> Melanie wrote:
>>> >>> Hi,
>>> >>>
>>> >>>
>>> >>> Justin Clark-Casey wrote:
>>> >>>> Cons
>>> >>>>
>>> >>>> 1.  LLEntity becomes very large and potentially complex.  SOG and
>>> SOP are already large and complex.  It may be possible
>>> >>>> to improve this by further refactoring.
>>> >>> One large and complex class to make the other logic everywhere much
>>> >>> simpler. A worthwhile tradeoff, i'd say.
>>> >>
>>> >> Personally I disagree - any large and complex class is a result to
>>> be avoided.
>>> >>
>>> >> However, as I said, I suspect that it could be broken up somewhat
>>> (unless you want absolutely everything in a single
>>> >> class on principle).  For instance, all the inventory stuff should
>>> really be in a separate class, especially as one can
>>> >> imagine virtual environments either where prims don't have
>>> inventory, or where inventory is handled different (e.g. an
>>> >> inventory for the whole object rather than for individual prims).
>>> >
>>> > Yeh, I think that if you moved Permissions and Inventory into outside
>>> > classes that were used, a bunch of complexity would start to fall out
>>> of
>>> > the environment.
>>> >
>>> > Plus, we could get rid of the most evil of the partial classes out
>>> there. ;)
>>> >
>>> > Death to partials!
>>> >
>>> >       -Sean
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> ---
>>> >
>>> > _______________________________________________
>>> > Opensim-dev mailing list
>>> > Opensim-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>