Hello Johannmes
Johannes Brunen wrote:
> "Dirk Reiners" <[email protected]>
> schrieb im Newsbeitrag news:[email protected]...
>> Given that the GOs use a factory my approach would be to derive from the
>> GO that
>> you need, handle the new classes in the derived one and let the base one
>> handle
>> the standard classes. I'm not totally sure if that works for all GOs, we
>> might
>> have to rearrange things a little to simplify that, but that was the idea.
>> Once
>> you have that you can override the GO factory so that your new GO is used
>> instead of the old one.
>>
> I also think that the derived classes can (should) handle all the specific
> details of the particular classes. However, some of the GraphOp already do
> account for the well established core classes (e.g. MergeGraphOp).
yes and for cores that are part of OpenSG just fixing the existing
GraphOps to handle them correctly is probably the right thing to do. I
guess Dirk (and I as well) were a bit confused whether you were asking
about what to do with your own cores or if you are encountering problems
with existing cores.
> My
> impression is that these base classes need a minimal awarness of the new
> group cores. E.g. the MergeGraphOp::isGroup is imho such a case.
hm, yes. Although in that specific case I'm almost tempted to fix it by
testing:
core->getType() == Group::getClassType()
That may be a bit conservative, but would avoid nasty surprises if new
group cores are added.
Cheers,
Carsten
------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
