On Mon, Feb 23, 2004 at 10:22:43PM -0800, Brent Dax Royal-Gordon wrote: : (Apologies if this is a repeat--I tried to send something on the same : subject a few days ago, but apparently it didn't get through.) : : A few weeks ago, my father and I were discussing Perl. (He is a : professional programmer of about twenty-five years; the last seven or so : have been spent building Visual FoxPro apps for a major financial : institution.) I ended up explaining Perl's module loading mechanism to : him; he agreed that the concept was elegant, but thought that calling : the subroutine "import" was a bad idea, because it kept users from : creating a sub with that name for other purposes. : : It occurred to me that Perl has a "syntax" in place for dealing with : this problem--subroutines with special purposes have names in all-caps. : (Besides all the blocks like BEGIN and END, consider DESTROY. I also : seem to remember that there's an all-caps object initializing method in : Perl 6.) I suggest that this mechanism be extended to import, making it : IMPORT instead. This would return to the module writer's domain a : common English word that is often used in computer contexts, which is : probably a Good Thing.
Yes, it's a pretty good idea. In fact, RFC 74 proposes the same thing. But I classified it under Apocalypse 11, Modules, which we skipped over to get to Objects first. So it hasn't actually been discussed much. : Of course, this entire post assumes that import isn't going away entirely. Well, there has to be a general hook for it, and IMPORT is about as good a name as any, if we need a name. Though most modules won't in fact define an IMPORT--most exportation will be done simply by marking the routines and variables in question "is exportable" or some such. The default importer (whatever its name) will know how to find those names and alias them. Interestingly, the module name itself might be aliased, since the module's full name might include author and version information. When you use a module without specifying those things, you get wildcarded to the most recent available version. But if you specify them, you get the one you want. In either event, the short name for the module is really an alias to the complete name, so if module A uses module C, and module B also uses module C, they might in fact be using two different versions. There will probably need to be some additional discipline to let these different versions share those resources that can be shared. Doubtless this involves factoring out the shared resource in some kind of OO-ish. And in fact, the same version aliasing can happen with classes and roles, since they're all just fancy packages. Though we have to think through how inner packages work--they probably just track the version number of the file they're in, whether the file defines a class or a module. But that's for A11. Larry
