Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Since you are writing object-oriented perl, it is a <em>very bad idea</em> to import symbols from one package into another. The inheritance the Perl's standard mechanism will work fine, and all you seem to be doing here is renaming the imported methods.</p> <p>The problem is that <code>use parent</code> doesn't call the other package's <code>import</code> routine, so <code>build_gmorn</code> is never imported into <code>mB</code> as <code>gmorn</code>.</p> <p>In addition, as your error message says, <code>gmorn</code> is not exported by the <code>mB</code> module, so it cannot be imported into <code>mFr</code>.</p> <p>If you change <code>mB</code> to look like this then your code will mostly work. Note that because there is no <code>mA.pm</code> I have had to write <code>mA-&gt;import('gmorn')</code> as the correct <code>use mA 'gmorn'</code> would fail.</p> <pre><code>package mB; mA-&gt;import('gmorn'); use parent -norequire, 'mA'; use Sub::Exporter -setup =&gt; { exports =&gt; { gmorn =&gt; undef, gnite =&gt; \&amp;build_gnite } }; sub build_gnite { my ( $class, $name, $arg ) = @_; return sub { say "$arg-&gt;{salutation}"; } } </code></pre> <p><br/></p> <hr> <p><strong>Update</strong></p> <p>There is no way to get the parameters to <code>use Sub::Exporter</code> to "pass through" multiple levels of <code>use</code>, because the <code>import</code> subroutine needs to call the generator function. So in your example <code>mB::import</code> needs to call <code>mA::build_gmorn</code> but it has no knowledge of that subroutine so it cannot be done.</p> <p>The only convenient solution is to export <em>both</em> the generator and a generated subroutine, so that the calling code can either use the function or export a generated function itself.</p> <p>This set of programs works fine.</p> <p><strong>mA.pm</strong></p> <pre><code>use 5.010; use warnings; package mA; use Sub::Exporter -setup =&gt; { exports =&gt; [ 'build_gmorn', gmorn =&gt; \&amp;build_gmorn, ] }; sub build_gmorn { my ( $class, $name, $arg ) = @_; return sub { say "$arg-&gt;{salutation}"; } } 1; </code></pre> <p><strong>mB.pm</strong></p> <pre><code>use 5.010; use warnings; package mB; use mA qw/ gmorn build_gmorn /; use parent 'mA'; use Sub::Exporter -setup =&gt; { exports =&gt; [ 'build_gmorn', gmorn =&gt; \&amp;build_gmorn, 'build_gnite', gnite =&gt; \&amp;build_gnite ] }; sub build_gnite { my ( $class, $name, $arg ) = @_; return sub { say "$arg-&gt;{salutation}"; } } 1; </code></pre> <p><strong>mFr.pl</strong></p> <pre><code>use 5.010; use warnings; package mFr; use parent 'mB'; mB-&gt;import( gmorn =&gt; { salutation =&gt; 'Bon Jour' }, gnite =&gt; { salutation =&gt; 'Bon Nuit' } ); sub new { return bless {}, shift } my $obj = mFr-&gt;new; $obj-&gt;gmorn(); $obj-&gt;gnite(); </code></pre> <p><strong>output</strong></p> <pre><code>Bon Jour Bon Nuit </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POcan't specialize parent class methods when using Sub::Exporter in a module subclassing a module using Sub::Exporter
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBorodin
    1. USBorodin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI think you've overlooked the fact that I'm specializing the methods, not simply renaming them. (That's the only reason I'm using Sub::Exporter). They *have* to be imported into the sub classes so that they get the specialized versions. The error message that I report is coming from Sub::Exporter, not from Perl itself. That's why I'm asking about inheritance of Sub::Exporter specifications. (added in edit: You're code doesn't allow specializing the `gmorn` method).
      singulars
      1. PO
      1. USDiab Jerius
    2. CO@DiabJerius: I have added to my answer what I think is the only solution
      singulars
      1. PO
      1. USBorodin
    3. COThanks. Another approach is to explicitly construct an exporter via Sub::Exporter::build_exporter, use a custom import() to strip known arguments out of the import list, pass them to the local exporter and pass the rest to the super class's import(). That would solve the problem of needing to know what the superclass is doing. It does require reproducing much of what's in Sub::Exporter::build_exporter. What I'd really like is a "pass_through" mode as in Getopt::Long, which would remove identified options from the import list. I'd simply pass the rest up to the parent's import.
      singulars
      1. PO
      1. USDiab Jerius
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload