Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a convenience package name #44

Open
cafarm opened this issue Aug 4, 2018 · 1 comment
Open

Add a convenience package name #44

cafarm opened this issue Aug 4, 2018 · 1 comment

Comments

@cafarm
Copy link
Member

cafarm commented Aug 4, 2018

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
Copy link

Khlick commented Jun 29, 2020

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)
      [email protected](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)
      [email protected](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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants