In answer to the OP: I have never tried subclassing a primitive data type. That I suspect is the source of the problem here and I am surprised it works at all. How are the superclass methods of double, which are MATLAB built-ins expecting IEEE doubles as input going to cope with a MATLAB object?
@Daniel's suggestion in the links he provides of overloading class is similar to something I have done in the "nakhur" class and its subclasses in the sigTOOL and the Project Waterloo File Utilities but does not seem to solve the above problem with built-ins. However, those classes do what the OP seems to be trying to do and work fine:
They provide a MATLAB OOP wrapper for primitive data - typically represented as a memmapfile object but also (within the same instance) as MATLAB arrays or GPU based arrays. To see all the tricks - see the code at http://sigtool.sourceforge.net/. Essentially:
subsref is overloaded to return the relevant data from the wrapped array
The size method is overloaded to report the size of the wrapped array.
The "isa" and some other methods are overloaded to report the result for the wrapped array (which is OK because of the overloading of subsref).
These objects cannot be passed to MATLAB built-ins, but they can be passed to most m-files, including those in the MATLAB toolboxes, where they behave as though they were the arrays passed back by subsref.
What's the point? Examples:
A wrapped memmapfile object behaves line a standard MATLAB matrix instead of needing special treatment - so works with the toolboxes.
If a large int16 array, e.g. from an ADC is wrapped, the object can wrap the 16 bit data but apply a scale and offset to return double 'real world unit' results via subsref.
sigTOOL has been using these methods since the mid-2000's - and no users have reported bugs related to the methods so far, so despite the apparent potential occasionally to trip up MATLAB, they seem to work.