ConstructOnLoad attribute for custom event.EventData objects?

Reading the documentation on the creation of custom event.EventData objects I found the following puzzling note:

To save and load objects that are subclasses of event.EventData, such as ToggleEventData, enable the ConstructOnLoad class attribute for the subclass.

Checking further , I found that ConstructOnLoad allows one to automatically call the constructor of a class upon 'deserialising' a class from a .mat file.

However, for that to work, there should be a constructor with no arguments:

Ensure that MATLAB can call the class constructor with no arguments without generating an error.

However, in the doc on event.EventData, an example is given with a constructor that takes a parameter and without a loadobj!

classdef (ConstructOnLoad) ToggleEventData < event.EventData
   properties
      NewState
   end

     methods
        function data = ToggleEventData(newState)
           data.NewState = newState;
        end
     end
  end

This is highly confusing to me.

No mention is made as to why it would be smart to add the ConstructOnLoad attribute and what would be the consequence of not having it. No background is provided.

This will cause users to add the attribute by default without knowing what it is for.

As such, the documentation should probably be improved.

That being said, I would love to hear from the experts what would be the reason for adding the attribute.

Thanks,

Kris

Answer 1

[Guillaume]

The relevant documentation about ConstructOnLoad is at http://www.mathworks.com/help/matlab/matlab_oop/passing-arguments-to-constructors-during-load.html. I agree that finding that in the documentation is not easy. The search function in the doc is rubbish.

I agree with you that the note is inconsistent with the example. If you can, you should raise a bug report with matlab. If you tried the deserialise the event object, it would probably cause an error (that possibly matlab would ignore, I haven't tested).

It probably doesn't matter anyway as I can't see many use cases where you'd want to serialise event arguments, particularly since serialisation in matlab is limited to saving to a file. If you do need to serialise the object, you can also override the loadobj method and then not have to worry about ConstructOnLoad.

In my opinion, serialisation/deserialisation in matlab is badly implemented. loadobj itself has plenty of limitations. Every single time, I've wanted to implement custom deserialisation (to support old object schemas for example) I've run into major problems that couldn't be worked around: can't support immutable properties, can't deserialise member objects that have changed name, etc. Unfortunately, MathWorks does not seem to want to improve on that.

[Kris Janssen]

Hi Guillaume,

Thanks for the speedy reply.

Your comments seem to confirm my suspicion that indeed, the remark about ConstructOnLoad is a bit out of place and could only add to confusion.

Why on earth would you want to serialize event data anyway as opposed to some kind of business model object that actually uses the EventData.

I have raised a report on that particular help page...

[Guillaume]

One scenario I could see for serialisation would be to send an event to a remote machine. That is normally done by serialising the event to a string or a stream of bytes, sending that over TCP, and deserialising on the other end.

That's not possible with matlab since you can only serialise to file. Unless you write to file, read the file, send the file content over tcp, save the tcp stream as file at the other end, and deserialise from the file. Really clunky.