Front page | perl.perl5.porters |
Postings from May 2021
Re: PSC #021 2021-05-21
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, May 23, 2021 9:30 AM, Neil Bowers <firstname.lastname@example.org> wrote:
> Neil proposed a way forward with trim. Expect a separate email on that to p5p RSN. Once that's done, we also want to kick off a review of text/string processing functions. Expect a separate mail on that next week.
In any case, the most concerning aspect of "trim" (or "whim") for me is how it was implemented. Not only the cookie-cutter nature that opens the door for all kinds of silliness (and therefore must be only used judiciously); but the more so the fact that it took took many lines of (necessarily?) grotesque* C/perl API code to implement what can be done in an extremely terse regular expression. In this case, it's clear to me that "trim" has absolutely no business being added internally in the way it currently has been proposed.
Moving forward, I request that in addition to assessing the "need" for "string" functions, there is also some deliberation on *where* these things belong. This should extend not only to "string" functions, but all extensions to "perl core". Ultimately, I'd really like to see this arrive at this more "humane" and "sane" approach to not only providing potential (or experimental) features for "market testing"; but also as a method of finding where they appropriate sit.
What does that mean? Differentiate between perl "userland" features that can be done in CPAN in pure perl or babby XS and those that require laborious XS implementations - and therefore would benefit from actual "core" support. It also means, define a formal path that is suitable for 99% of "features" that starts with placing it in CPAN and resulting in a "dual life" module. It seems to me that only in the most rare situations should a feature actually require new core features or extending something that's already supported.
I don't like to shit up p5p about this again, so if I can could be directed to the appropriate email addresses; I'll happily summarize what I envision as a reasonable approach for consideration by the PSC. And it may be burned in effigy for all I care, as long as it helps move us into some sanity regarding the discovery, deliberations, and market testing of useful and interesting "features" (wherever in the perl "stack" they may be implemented).
* if you think I am being harsh, it might be my ignorance showing; however I recommend anyone interested take a look at what I mean. No offense to the original author is intended. But the method employed to "extend" perl seems to be ripe for inviting all kinds of crap in the future (again, I could also be super ignorant).