keeping types out of the core

[John W. Eaton]

On  4-Aug-2004, Paul Kienzle <address@hidden> wrote:

| Please try to keep types out of the core.

OK, I think you have mentioned in the past that you would like all
types to be implemented in the same way so that there is no particular
distinction between a built-in type and a user-defined type.  For that
to be true, we would need to eliminate the need for many of the
octave_value constructors that take specific types and the member
functions that check type information and extract values of specific
types (possibly doing conversion)

Currently we can do things like

  NDArray ra = ...;

  return octave_value (ra);

or

  octave_value v;

  if (v.is_matrix ())
    {
      // do something specifically for matrix types
    }

or

  NDArray ra = args(0).array_value ();

  if (! error_state)
    {
      // do something with ra.
    }

for built-in types which can't be done for user-defined types.

In the first case, we can already construct octave_value objects using

  return octave_value (new octave_matrix (ra));

and this will work for any octave_value subtype.

For the second, we can switch to using run time type identification on
the internal representation of the octave_value object.

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.

| However, (2) it would be nice to be
| able to define as few primitives as possible on a new type (e.g., 
| +,-,*,/, > ...)
| and immediately have that type available in real/complex
| scalar/vector/matrix/nD-array/sparse.  So maybe have the templates in
| liboctave (along with support code so that the templates are as small
| as possible), but keep the instantiation of each type separate in
| DLD-FUNCTIONS?

Yes, that would be nice.  I think we have a bit of work to do before
we get there.

jwe