Clear Filters
Clear Filters

How to make calls to static methods independent of packaging structure (name)?

3 views (last 30 days)
I have the following class:
classdef TestStaticMethodPackage
methods (Static)
function hello
fprintf("Hello world\n");
function write
I run it:
>> TestStaticMethodPackage.write
Hello world
I am now trying to organize my code into a package:
>> !mkdir +TestPackage
>> !move TestStaticMethodPackage.m +TestPackage\
Trying to run now:
>> TestPackage.TestStaticMethodPackage.write
Unable to resolve the name 'TestStaticMethodPackage.hello'.
Error in TestPackage.TestStaticMethodPackage.write (line 9)
This behavior breaks essentially all static methods, and requires the classes to be aware of their external environment. Is there a simple workaround to make it flexible to work in any package structure without having to change all calls where static methods are used?
I was thinking about writing some static method launcher based on dbstack and eval but what's making things worse is that dbstack does not see the package name in front of the class name. Adding the following line before TestStaticMethodPackage.hello; line in class definition:
s = dbstack('-completenames')
results in:
s =
struct with fields:
file: 'C:\...\+TestPackage\TestStaticMethodPackage.m'
name: 'TestStaticMethodPackage.write'
line: 9
'name' seems inconsistent, since even within the class itself I need to prepend package name to class name to call a static method.
Jiri Hajek
Jiri Hajek on 14 Dec 2022
Hi, it seems that you want to run code that is not on the MATLAB path. It is not clear why you should want this, as you can easily "addpath", if its really important for you. You want to build a compiled app and be able to run it anyway or what is the purpose of this?
Also, you are using funny name for your directory (note the "+" sign within the folder name. Matlab is generally sensitive about special characters on the path.
Robert Borkowski
Robert Borkowski on 14 Dec 2022
Edited: Robert Borkowski on 14 Dec 2022
Hi Jiri, + is not a "funny name". It is a prefix used to identify a package directory Packages cannot be added to path using addpath.

Sign in to comment.

Answers (2)

chrisw23 on 13 Dec 2022
try to set a session path (addpath) and import the package path (i.e. import MyPackageRoot.TestPackage.*)
Robert Borkowski
Robert Borkowski on 13 Dec 2022
Edited: Robert Borkowski on 13 Dec 2022
Hi Chris,
That's not really a solution. In the example above I only have one level of packages: TestPackage, which already is in the working directory.
After running import TestPackage.* I can then of course make calls in the current scope, but it does not solve the fundamental problem of calls to static member method inside of the same classdef, which happen in the scope of another static member method:
>> import TestPackage.*
>> TestStaticMethodPackage.write
9 TestStaticMethodPackage.hello;
Unable to resolve the name 'TestStaticMethodPackage.hello'.
Error in TestPackage.TestStaticMethodPackage.write (line 10)
The only way I can to solve this problem is to make changes in each and every static method, and do a dynamic import that will include potential hierarchy of pacakges names. It seems to be "broken by design".
chrisw23 on 16 Dec 2022
Edited: chrisw23 on 16 Dec 2022
Path ..MatLabClassExample\+TestPackage\@TestStaticLibrary
TestScript at MatLabClassExample dir
import TestPackage.*
str = "direct static call: " + TestStaticLibrary.hello()
myStaticLib = TestStaticLibrary();
str = "indirect static call: " + myStaticLib.write()
classdef TestStaticLibrary < handle
% requires handle super class
properties (SetAccess = public, GetAccess = public)
% to be defined
methods (Access = public)
function obj = TestStaticLibrary()
% construcor
function delete(~) % ~ replaces unused obj argument here
% destructor
%% my public methods
function str = write(obj)
str = obj.hello;
%% private methods
methods (Access = private)
%% static methods
methods (Static)
function str = hello
str = "Hello world";

Sign in to comment.

Walter Roberson
Walter Roberson on 16 Dec 2022
Known work-arounds:
  • preprocessing the source code to convert some kind of relative reference to absolute reference before executing
  • pass down the package names in calls so that you can dynamically generate the import statements (does not play well with compilation)


Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!