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

[Melanie]

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