in reply to "use" modifier code via import()

First of all I should note that Exporter offers export_fail which can be used for the same purpose. You can glance at the implementation of Carp to see how you might use it.

In the past (particularly with Perl 5.6) I've noticed that export_to_level does not work exactly like you would want. (It reports errors at the wrong level.) Therefore this alternate strategy may be more reliable.

I also notice that you are using prototypes in your definition of sub1. There was an excellent article on perl.com explaining prototypes in Perl and demonstrating why they are problematic. Unfortunately the link to it isn't working very well at the moment, so I can't direct you to read that article. But I can assure you that if your understanding of prototypes are shaped by prototypes in any other language, that Perl's version of the same is pretty definitely not what you want, and you're better off forgetting that you ever heard about them.

I also have to second perrin's comment. While playing around with export semantics can achieve all sorts of cool effects, unless it is really important for what your module does, it is better programming practice to stick to normal export semantics and not overload your export semantics.

Replies are listed 'Best First'.
Re: Re: "use" modifier code via import()
by pbeckingham (Parson) on May 18, 2004 at 00:43 UTC

    First of all I should note that Exporter offers export_fail which can be used for the same purpose.
    Yes, but while I am currently overriding import and removing the two items from the list, in this case I would override the export_fail method and remove two items from the list there. As I see it, both implementations are similar, but I will take a look at Carp.
    (It reports errors at the wrong level.) Therefore this alternate strategy may be more reliable.
    Agreed. That makes for better diagnostics.
    There was an excellent article on perl.com explaining prototypes in Perl and demonstrating why they are problematic. ...
    Oh no! Has the camel misled me? Are prototypes not what I thought? I do enjoy the diagnostics on erroneously constructed sub calls, but is there a downside? I couldn't find an article on perl.com about this. Is there a PM article containing same? I couldn't locate one.
    I also have to second perrin's comment. While playing around with export semantics can achieve all sorts of cool effects, unless it is really important for what your module does, it is better programming practice to stick to normal export semantics and not overload your export semantics.
    I wouldn't say it's really important for the module, just a stylistic preference, with some notion of clean-looking client code.

    Thank you. I appreciate the considered response.

[reply]
[d/l]
[select]
      As far as I know, no perlmonks article exists covering the problems with prototypes for the simple reason that people always point to Christensen's. But it has been discussed, see When to use Prototypes? or Are prototypes evil?.

      As for whether the Camel mislead you, probably not. You probably mislead yourself. Prototypes do exactly what the Camel tells you that they do. Whether you noticed the consequences of the same is another story.

[reply]

In Section Seekers of Perl Wisdom