in reply to Re: functional functions
in thread functional functions
BTW Perl 6 has a nice solution to the builtin flood: nearly all builtins are methods, ie they belong to a class, and therefore don't exists as "global" functions.
Based on previous conversations, I know you know better than I do, but I believe that more precisely a nice work of reorganization is being made: stuff that would better exist as a method will, and stuff still better suited to be a "plain" function will. Actually the current Synopsis 29 lists quite a lot of them, but perhaps the most interesting part to note is what the document itself writes of builtin functions:
In Perl 6, all builtin functions belong to a named package (generally +a class or role). Not all functions are guaranteed to be imported into the global package C<::*>. In addition, the list of functions imported into C<::*> will b +e 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 thei +r full name. After 6.0.0 comes out, global aliases will not be removed lightly, and will never be removed at all without having gone through a deprecation cycle of at least a year. In any event, you can specify that you want the interface for a particular version of Perl, and that can be emulated by later versions of Perl to the extent that security updates allow.
Speaking of methods, one thing that they will replace with a very good overall effect is the bazillion of special variables: granted, they were a very concise and convenient way to do things but are often misleading due to the fact that they're too loosely coupled with the things they do, and the stuff they act upon. So some will regret them and I bet I occasionally will too, but not too much...
|
|---|