Add a convenience package name

[cafarm]

Importing Symphony stuff from packages is quite a bit of typing. It would be nice if there was a convenience package with a short name like sym so the a user could write something like sym.Protocol instead of symphonyui.core.Protocol and sym.ResponseFigure instead of symphonyui.builtin.figures.ResponseFigure.

[Khlick]

I have a thought about this. It could be as simple as providing a package of Abstract class definitions and some related "how to" documentation or in the examples. What I've done is create a, sort of, abstraction layer between the core classes (or builtin) and the user. But, I've also added some properties and methods to the class to make the protocol slightly more specific for our need, e.g. I have an abstract LEDProtocol class in a package folder (say, +pkg) where I extend the only the didSetRig() method to create properties for LEDs bound to the rig:

classdef (Abstract) LEDProtocol < symphonyui.core.Protocol
  properties
    led1
  end
  properties (Hidden)
    led1Type
  end

  methods
    function didSetRig(obj)
      didSetRig@symphonyui.core.Protocol(obj);
      [obj.led1,obj.led1Type] = obj.createDeviceNamesProperty('LED');
    end
  end
end

Then the user can create a simple protocol like so:

classdef singleLedPulse < pkg.LEDProtocol
  % protocol properties without the need for led1, led1Type.
  methods
    function didSetRig(obj)
      didSetRig@pkg.LEDProtocol(obj);
      % extend didSetRig...
    end
  end
end

A benefit of this approach is that the ClassRepository already filters out abstract classes so there wouldn't have to be an entry in the exclusion filter. Plus, the abstract class could contain nothing but the help doc comments and, without a constructor method, it shouldn't add any appreciable overhead. Also, existing custom protocols wouldn't need to update to the shorthand package, which is great because MATLAB's search/replace is so painful especially when compared to the "search across folders" feature in VSCode.

NOTE ON EDIT: I removed dynamicprops from the example because in order to use dynamic properties on a protocol, one has to override the getPropertyDescriptor method in admin.core.Protocol to prevent the static method, fromProperty, in admin.core.PropertyDescriptor which fails because it relies on the meta class object property, DefiningClass, being set but which is always empty in dynamic properties. (Perhaps that could be a new issue?)