Re: keeping types out of the core

[Paul Kienzle]

On Aug 6, 2004, at 12:07 AM, John W. Eaton wrote:

> And, to replace the member functions that do extraction, we could
> write
>
>   NDArray ra = as_NDArray (args(0));
>
> with the definition of as_NDArray looking something like
>
>   NDArray
>   as_NDArray (const octave_value& v)
>   {
>     NDArray retval;
>
>     const octave_value& rep = v.get_rep ();
>
>     try
>       {
>         const octave_matrix& m = dynamic_cast<const octave_matrix&> (rep);
>         retval = m.array_value ();
>       }
>     catch (std::bad_cast)
>       {
>         error ("invalid conversion from %s to NDArray", typeid(rep).name ());
>       }
>
>     return retval;
>   }
>
> though with this implementation, I can't see a good way to allow
> automatic type conversions on user-defined types since these as_*
> functions can only know about particular sets of types.  Do you see a
> good way to allow automatic conversions?  This is currently handled by
> allowing the sub-types to define extractors for multiple types of
> objects.

One approach would be to check if it is already of type XXX.  If it
is then you are done and you can return it.  If it is not, then you
can call the constructor for the type with the value and leave it
up to the dispatch system to call the correct function for the
conversion.  So for example if you want sin() to do automatic
conversion to double on its argument, then something like:

        x = uint8(7);
        sin(x);

would be interpreted at run-time as:

        x = uint8(7);
        sin(x.typeid==doubleid?x.rep:double(x));

Under octave-forge, this would be done using dispatch:

        dispatch("double","uint8_double","uint8")

The function uint8_double would look like something like the following:

  DEFUN_DLD(uint8_double,args,,"...")
  {
    NDArray ra();
    oct_uint8 x(as_uint8(args(0)));
    ... fill up the return array ...
    return octave_value(new octave_matrix(ra));
  }

It's still not clear to me how sin() will handle real vs. complex unless
complex is a property of the octave base class. Hopefully the details
won't degenerate into a complicated system of type hierarchies where
the runtime system has to check for ambiguous conversions between
various types.

- Paul