Irony of import

On the lighter side -- along the lines of noting how we "park on a driveway and drive on a parkway": over the weekend, in pondering the role that symbol exporting plays or should play in Perl OO design (c.f. Spiffy), it struck me as amusing that when I want some module to export its functions into a mine, I call that module's "import" sub, which is provided by a module called the "Exporter".

Anyone know the original rationale for this? For such a linguistically sensitive language as Perl, I'm surprised. Unless it came out of the flirtation with indirect object syntax:

require SomeModule;
import SomeModule;
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Irony of import Download Code

Replies are listed 'Best First'.
Re: Irony of import by adrianh (Chancellor) on Aug 22, 2005 at 12:16 UTC
Anyone know the original rationale for this? For such a linguistically sensitive language as Perl, I'm surprised. Unless it came out of the flirtation with indirect object syntax: Makes perfect sense to me. You see "Exporter" in the place where you define the things you want to put in somebody else's name space. You see "import" in the place where you want to put the things. Two different sides of the same operation.	[reply]
Re^2: Irony of import by xdg (Monsignor) on Aug 22, 2005 at 14:10 UTC
Except that if you want to customize the export, you don't use Exporter and write an "import" function instead. I grok it, but that's because I'm used to it -- it just struck me suddenly as kind of funny. If designing from first principles, I'd be more inclined to have the builtin "importing" function (aka `use`) call a module's "export" function. That way, the function name is a command. "When I want to import, I tell it to export." -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l]
Re^3: Irony of import by adrianh (Chancellor) on Aug 29, 2005 at 13:50 UTC
If designing from first principles, I'd be more inclined to have the builtin "importing" function (aka use) call a module's "export" function. That way, the function name is a command. "When I want to import, I tell it to export." And then you'll have somebody come along and ask "why when I add stuff to my symbol table do I call export - surely I'm importing stuff?" :-) You can argue it either way.	[reply]
Re: Irony of import by davorg (Chancellor) on Aug 22, 2005 at 12:31 UTC
When explaining this in training courses I like to have a large flipchart with a vertical line down the middle. The left hand side is labelled "your_app.pl" and the right hand side is labelled "SomeModule.pm". I then draw in links between the two symbols tables to show how symbols from SomeModule are exported into your_app (or, alternatively, how your_app imports symbols from SomeModule). All the time I'm leaping from side to side of the flipchart to demostrate how imports from one point of view are exactly the same thing as exports from the opposite point of view. -- <http://dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re: Irony of import by BrowserUk (Patriarch) on Aug 22, 2005 at 13:01 UTC
Irony. Is that like Goldy and Bronzy, 'cept it's made of Iron? :) Kind like the guy that left as an emigrant and arrived as an imigrant. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply] [d/l]
Re: Irony of import by Fletch (Bishop) on Aug 22, 2005 at 13:17 UTC
Luke, you're going to find that many of the truths we cling to depend greatly on our own point of view. Of course Ruby does use almost that same syntax for pulling methods from modules into another namespace (`s/import/include/`, but otherwise that's it). -- We're looking for people in ATL	[reply] [d/l]
Re^2: Irony of import by tye (Sage) on Aug 22, 2005 at 15:32 UTC
Of course Ruby does use almost that same syntax for pulling methods from modules into another namespace (`s/import/include/`, but otherwise that's it). So the Ruby module to implement that is called Excluder? - tye	[reply]
Re: Irony of import by QM (Parson) on Aug 22, 2005 at 19:29 UTC
I think xdg is pointing to the duality of it (or perhaps more towards the relative reference frame). As BrowserUK said: `Kind like the guy that left as an emigrant and arrived as an immigrant +.` [download] When we ask someone to ship us something from another country, we don't ask them to export it, we ask them to import it. From our reference point, it's importing. They automatically translate the request into a sequence of actions that are best classified as exporting. Very early in our development we learned to make the automatic translation of "I am going now" to mean the speaker is going, and not the listener. Perhaps a good party game is to have everyone talk in speaker-relative instead of listener-relative, and try to have a conversation. -QM -- Quantum Mechanics: The dreams stuff is made of	[reply] [d/l]