Front page | perl.perl5.porters |
Postings from November 2011
On Fri, Nov 11, 2011 at 1:04 PM, Nicholas Clark <nick@ccl4.org> wrote: > "I find this very useful and it is something that is in my core toolkit" For me, the more primitive the task, the more it looks like something that should be in core -- and possibly compiled in rather than just a module in core. Several of the Scalar::Util functions come to mind. (And, yes, I recall the "mauve" discussion.) Something that is the only sane/safe way to do a not-uncommon task seems more like something that should be in core. (Examples fail me at the moment.) Way down the priority list for me is making very common tasks less verbose, but a few might reach the threshold for me that "by gosh, this should just be built-in". File slurping is probably top on my list. The module-free idioms are horrid to look at. > in some cases its also "PHP has this big advantage over Perl on low end > hosting because it comes with X by default; without X we can't do Y" That is the "kitchen sink" argument wrt. Python. I'm happy to finally have out-of-the-box HTTP client capabilities (which is why I spent the time with Christian Hansen on it), but that was as much to ensure CPAN bootstrapping as anything else. > It's also the case that an argument for X is that X is the only XS > prerequisite that common task Y needs. I don't care for that argument either, unless it's a primitive looking task (as mentioned) and/or it's tightly coupled to some internal implementation detail. Some XS thing "because it's faster" wouldn't cut it for me. > But we've fundamentally *not* solved the problem of the Perl 6 RFC process > back 10 years ago - 361 proposals, most of which were "Perl 5 is great, apart > from these 1 or 2 deficiencies that I'd like to see addressed": I wonder what that list would look like if triaged for whether it could be done within the current interpreter and without impacting back compatibility (with or without a version declaration). > Currently most concerns seem to be about meta models, highlighted by what > Moose needs. I can see that. Symbol-table hackery like namespace::autoclean (and friends) also makes me cringe (as useful as it is) because it exposes a conceptual gap in the way Perl does methods. I might want to *import* a function to use (for convenience instead of explicitly using it's full name) without *exposing* it as a method. Perl programmers' use of underscore to signal "private" functions/methods is another example where a convention has sprung up to cope with the lack of any real privacy model within the language. Those kinds of gap seem like the sort of thing that are worthy of core attention, even if they can be solved outside it. -- DavidThread Next