"Ron Lu" <email@example.com> wrote in message news:firstname.lastname@example.org... > "Steven_Lord" <email@example.com> wrote in message > <firstname.lastname@example.org>... >> >> >> "Ron Lu" <email@example.com> wrote in message >> news:firstname.lastname@example.org... >> > "Nick Clark" wrote in message <email@example.com>... >> >> Hi all, >> >> I have a query regarding inheritance of one class by another within a >> >> package. For example, classB < classA within package mypack. From >> >> outside the package directory I type: >> >> >> >> import mypack.* >> >> x = classB >> >> >> >> . . then I get an error saying that classA cannot be accessed. I can >> >> resolve this by making classB < myclass.classA at the top of the >> >> classdef of classB. However, this seems like a bit of a clunky 'duct >> >> tape' kind of work around. It also causes problems when trying to >> >> display the documentation about the classes which are linked in blue >> >> from the disp command. >> >> >> >> What is the recommended elegant method for inheritance within a >> >> package? >> > >> > Anyone can help? >> > >> > I ran into the exact same problem. >> > I already finished all my classes and now want to put them into >> > different packages. And I HAVE TO add those import statements >> > everywhere, or add packageName.Class* to let the class know where to >> > find dependencies in the same package. >> >> That is correct. >> >> > Is there a way to work around? >> >> No. Packages define a namespace, and the package name is sort of part of >> the name of the class. >> >> As a concrete example, if you had this directory structure (with >> mydirectory on the path): >> >> mydirectory\classB.m >> mydirectory\+mypack\classA.m >> mydirectory\+mypack\classB.m >> >> and you wanted to create an instance of the class defined in the classB.m >> file inside +myPack from within the classA.m file, you would need to use >> mypack.classB. If instead you wanted to instantiate an instance of the >> mydirectory\classB.m class, you would simply use classB. [If you imported >> mypack.classB inside classA.m, I don't believe you'd be able to access >> the classB class defined outside the package in the function in which you >> imported.] >> >> -- >> Steve Lord >> firstname.lastname@example.org >> To contact Technical Support use the Contact Us link on >> http://www.mathworks.com > > Thank you Steve! > > I find that even when I call classA's method within classA (like one > method uses another), I also need to use mypack.classA.method1 in > classA.method2.
For _static_ methods, yes. The package name is sort of part of the name of the class, and to call a static method you need <name of the class>.<name of the static method>. There is usually no instance of the class involved in a static method call, so MATLAB needs a different way to know which class's method to call.
For non-static methods, no. If you call method1 with an instance of mypack.classA as input, the method that will be called is mypack.classA.method1. [Basically. I'm ignoring N-ary (N > 1) functions with multiple object inputs for simplicity.]
> Besides, import* only works within a method, then every class method > needs a import statement. That means if I redistribute my code in a > different package name, I will need to change all those package name > instances. Is that right?
Yes. Changing the package name in which your program files are located is a major reorganization of your code, and will likely require changes to users of your code (including your code itself.) Consider when a professional sports team changes its home city. Its name changes. Its logo changes. Its mascot may change. The equipment that has the team's old logo on it needs to change. The merchandise (T-shirts, hats, etc.) with the team's old name and logo need to change.
> Does Mathworks have a plan to enhance the way using packages?
I recommend that you contact Technical Support and describe the specific enhancements you have in mind for packages and the packages workflow to the Support staff. They can capture your use case and requests in the enhancement database, or may be able to suggest alternatives that I haven't thought of for ways to do what you want now.