Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I'm unsure if I should write use <name of module> in two special cases.

Special Case 1:

I'm in module A. This needs a functionality of module B. But it also needs the functionality of modules B1 and B2. B1 and B2 are inheriting from B. Or in other words B is the base class of B1 and B2.

Now in module A:

use B; # not necessary because B1 and B2 are using B. use B1; use B2;

Shall I write use B; or not. What is your opinion?

Special Case 2:

Class A has an object of class B inside and of course uses its functionality. Class A is not creating the object B. The object B is created somewhere else and to class A is given the already created object of B. Because the object B is created outside of class A, I can assume that the Module B was loaded before somewhere else. And thus writing use B; in class A would not be necessary. Would you write use B; in class A?

What is your opinion? Thank you very much!

Replies are listed 'Best First'.
Re: use of modules in special cases (updated)
by LanX (Saint) on Dec 21, 2019 at 21:35 UTC
    If you are using modules as OO classes then you don't need to import them again if they are already inherited.

    (Theoretically you might to import functions from these base classes too, but mangling OO and exporting is bad practice.)

    Update

    After reading choroba's answer... What do you exactly mean with:

    > This needs a functionality of module B.

    If you mean inherited methods in B1 objects , then the answer is no !

    If you mean objects constructed from B - i.e something like B->new() - then the answer is of course yes !

    ( for the reasons choroba listed.)

    If you mean something else please be more explicit.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: use of modules in special cases
by davido (Cardinal) on Dec 21, 2019 at 22:33 UTC

    No, you should not use B;.

    Child classes B1 and B2 handle all aspects of their inheritance from B. You should not need to use B unless you specifically want a B object.

    There are a lot of strategies for ensuring that B1 and B2 implement the full interface needed for them to be treated polymorphically as children of B. Role as interfaces, pure-virtual base classes (not as common in Perl), base classes that throw exceptions if an accessor is called without having been overridden in a base, and others.


    Dave

Re: use of modules in special cases
by choroba (Cardinal) on Dec 21, 2019 at 23:16 UTC
    In case 1, you should request B. The implementation of B1 and B2 might change in the future, if your code uses something coming from B, be explicit about it. If the classes are object oriented, it means in module A you build objects of all three classes B, B1, and B2.

    In case 2, you shouldn't specify the use clause. In fact, the object you get from elsewhere might in fact be of a different class, inheriting from B, or even duck-typed.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
Re: use of modules in special cases
by Dirk80 (Pilgrim) on Dec 22, 2019 at 07:06 UTC

    Sorry, by accident I wrote anonymous.

    It's all object oriented in my case. Here an update for special case 1. I'm calling a class method of B. B has an abstract constructor. So it is not possible to create a B object.

      Would it be possible to have B1 or B2 inherit this class method, so that you can call it as a subclass method?
      Then you wouldn't need to use B
      > I'm calling a class method of B.

      How? Please show code.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: use of modules in special cases
by Anonymous Monk on Dec 23, 2019 at 05:12 UTC
    Each module should be concerned with only its own actual needs – not its implementation at the then-present time. If A needs the functionality of B, B1, and B2, then "superficially" you should include all three ... while, perhaps, "idly wondering why this is so." What, exactly, is it about the present concept of "module A" that makes it simultaneously need not only knowledge of two subclasses, but also ("class-busting ...") knowledge of the parent class from which both of the other two were derived? "This smells bad..."
      "This smells bad..."
      Hmm... your writing style smells somehow, that may be the reason for some downvote. OTOH, what you say here, sounds mostly OK. On the third hand, all of it has already been said...