Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.


Math Forum » Discussions » Software » comp.soft-sys.matlab

Topic: Inheritance from classes withina package
Replies: 7   Last Post: May 24, 2013 3:57 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Steven Lord

Posts: 17,944
Registered: 12/7/04
Re: Inheritance from classes withina package
Posted: May 24, 2013 3:57 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply



"Ron Lu" <dlu@masimo.com> wrote in message
news:knlg51$ktq$1@newscl01ah.mathworks.com...
> "Steven_Lord" <slord@mathworks.com> wrote in message
> <knlbmr$6go$1@newscl01ah.mathworks.com>...

>>
>>
>> "Ron Lu" <dlu@masimo.com> wrote in message
>> news:knjldr$1rs$1@newscl01ah.mathworks.com...

>> > "Nick Clark" wrote in message <h9dqf5$e15$1@fred.mathworks.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
>> slord@mathworks.com
>> 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.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com




Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.