On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote: > On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: > : I ran into this problem while creating a mini-list of S29 functions > : (which Rod's work supercedes, I suspect, and I'm very glad he's taking > : this on). What are some guidelines we could use in deciding > : which functions are automatically in ::* ? Or is this just a case > : where we need to use past experience and best guesses as our guide?
> * Another confounding factor is that memes tend to come in bundles, > and you'd kind of like to keep the bundles together. So my earlier > question really amounted to whether POSIX was really a valid > bundle of memes. (Probably not.) On the other hand, the trig > functions might well be a valid bundle, and we might want to > keep them all together either in * or Trig.
To me it seems that a there are some groups of core builtins in Perl 5 that group conceptually quite well, and it's sensible to remove en mass, which are the builtins that aren't really useful in Perl 5 without loading an extension module. So all the socket related builtins aren't much use without the constants exported by Socket; and the System V IPC builtins aren't much use without the IPC::SysV, so they could quite easily be exported by that instead.
But then it gets less obvious what other groups from the top of perlfunc.pod might manage a discrete exit from ::* without anyone noticing. So, no, I don't have an answer :-)
Nicholas Clark
I've put the following note at the top of S29.pod (in an update I haven't posted yet).
In Perl 6, all builtin functions belong to a named package. Not all functions are guaranteed to be imported into the global package C<::*>. In addition, the list of functions imported into C<::*> will be subject to change with each release of Perl. Authors wishing to "Future Proof" their code should either specifically import the functions they will be using, or always refer to the functions by their full name.
-- Rod Adams
