Automatic conversion to subclasses

[GoogleCodeExporter]

What steps will reproduce the problem?

1. consider the following example:
{{{
import osg
a = osg.Vec3Array()
a.append(osg.Vec3(0,0,0))
a.append(osg.Vec3(0,0,1))
a.append(osg.Vec3(0,1,1))
a.append(osg.Vec3(1,1,1))
g = osg.Geometry()
g.setVertexArray(a)
b = g.getVertexArray()
}}}
now b cannot be iterated anymore

Original issue reported on code.google.com by gerwinde...@gmail.com on 26 Feb 2009 at 7:34

[GoogleCodeExporter]

this is a typical problem of (python) wrappers; the "getVertexArray"
returns a general Array, which is currently not wrapped. The trick
would be to somewhere "cast" the general Array back to its specific
type in Python, e.g. a Vec3Array. We've used some of these tricks in
the wrappings themselves by a dynamic_cast through C++ run-time type
information (not accessible to users), and some you can access
yourself, e.g. osg.Node.asLOD .

To fix your particular problem we might introduce extensions to Array
such as osg.Array.asVec3Array etc, or better would be to automatically
let SWIG convert all returning values of Array to its "real" type. In
any case this means diving into SWIG specifics.

Original comment by gerwinde...@gmail.com on 26 Feb 2009 at 7:36

[GoogleCodeExporter]

Could be something like this:

%typemap(out) osg::Array* {
    //  osg::Drawable.getVertexArray returns a raw Array* , but should be cast into
its specific type
    //  custom typemap to ensure a target-language-owned Node object, while
increasing reference counting
    //  alternative to %newobject directive, because reference counting had to be
included (?)
    if ($1)
    {
        $result = SWIG_NewPointerObj((void*)($1), $1_descriptor, SWIG_POINTER_OWN | 0);
        $1->ref();
#ifdef OSGSWIGDEBUG
        printf("osgArray::$symname:: Typemap Ref for Obj %x\n",$result);
#endif OSGSWIGDEBUG
    }
    else
    {
        SWIG_exception(SWIG_IOError,"osg::Array::$symname:: Could not cast");
    }
}

Original comment by gerwinde...@gmail.com on 26 Feb 2009 at 7:43

[GoogleCodeExporter]

This problem also occurs with the MatrixList type returned by 
osg.node.getWorldMatrices()

Original comment by rfritz...@gmail.com on 24 Mar 2009 at 1:04