in reply to How to create and install a module compatible with both UTF8 and Perl 5.8.3 without using non-core modules?

I don't want to require the installation of non-core modules. If there is not a better way to do this, my next version release will abandon all of those useful tests

You could pull this off with a little monkey patching and finagling but I think you're getting lost in the weeds again... Why on Earth would you avoid a module that has been in the perl core for almost eight years or make your test suite less complete for the arbitrary goal of supporting perl versions that are statistically irrelevant in 2023? Who are you targeting that stopped installing new versions of the interpreter 19 years and 11 months ago with v5.8.3? And if this person exists, why would they avoid updating perl itself-- ignoring two decades of improvements, security fixes, and features --only to install your brand new non-battle-hardened module tomorrow?

And if a module was non-core 8 years ago (or even today), so what? Your module is non-core. You put that code on CPAN because it serves a practical purpose and you want your work to be found, installed, used, and potentially improved upon by others; not avoided or ignored because it's not a core module. The CPAN itself wouldn't make much sense if we all avoided using each other's non-core modules. Besides, worrying that someone doesn't have a module "new" to the core or an entirely non-core module (or even a given version of a core or non-core module) pre-installed is a problem resolved long ago: properly define your prerequisites in metadata and, better yet, in a cpanfile.

Finally, the very first line of Test::More reads "STOP! If you're just getting started writing tests, have a look at Test2::Suite first." Emphasis is theirs. I'd take the advice because Test2 is where the effort is going today and in the future.

  • Comment on Re: How to create and install a module compatible with both UTF8 and Perl 5.8.3 without using non-core modules?
  • Download Code

Replies are listed 'Best First'.
Re^2: How to create and install a module compatible with both UTF8 and Perl 5.8.3 without using non-core modules?
by Polyglot (Chaplain) on Dec 03, 2023 at 01:17 UTC
    My module is for Thai. My next one may well be for Lao. If you do not know the state of Thailand and Laos with respect to computing, you can be forgiven for not understanding my reasons for wanting to do what I am doing. That said, I did not ask for opinions on my rationale--I asked, perhaps rhetorically, if there were even a way to accomplish this in the "politically correct" (properly tested) manner with utf8. With the gerry-rigging/hackish ways to do this brought up, it's clear that Perl is a bit behind on the unicode adoption spectrum. It should not be this difficult.

    FYI: As of about six years ago when I did my research on the subject, Laos was estimated to have about 15% internet saturation; i.e. 15% of the population of the country had internet access. Most of that was via smartphones, so consider that far fewer have actual computers. Thailand is more advanced, but not as advanced as one might wish. While Thailand is not on the United Nations' "least developed countries" list as Laos is, it has miles to go in terms of educating people with computing. Thai programmers are few.

    As it happens, only two weeks ago I was in a meeting with a number of Thai people trying to persuade them to convert to using UTF8, across the board, for their translation projects. It was a tough sell. They were quite accustomed to typing in their text using the local ASCII code pages and fonts tailored for them--fonts which, when copied into a text file, disappear, leaving the resultant text looking like garbledy-gook. It was only after we showed them superior tools for word-wrapping that they warmed up to the idea of switching to UTF8. Transitions here seem to take longer than they might in other places.

    Blessings,

    ~Polyglot~

      I did not ask for opinions on my rationale
      I thought since you posted this in public that you might want the public to respond. My bad, I guess.

      But get ready because I'm going to make the same mistake again.

      What ratio of Laotian or Thai users are developing new software on Windows XP? Or are they still targeting a linux kernel that predates the first release of Ubuntu? Because that's the era of perl 5.8.3. Today, P5P "officially" covers two stable releases according to perlpolicy; that's currently this year's 5.38.x release and perl 5.36.x from 2022. The perl toolchain folks (those behind core modules like CPAN.pm, ExtUtils::MakeMaker, etc.) have set their support window to 10 years which will put perl 5.20.x at the tail end of targeted support next summer. I imagine they've done their research as well.

      Anyway, do as you please (as I have here) but watering down tests, cribbing snippets of code to avoid installing pure perl prerequisite modules, ignoring all the encoding work done in perl itself since 2004... in general, just making the maintenance and development of your module more complicated for a dev environment that might not exist anywhere in the world... is a choice. มันไม่มีอะไร...

        What ratio of Laotian or Thai users are developing new software on Windows XP?

        I personally do not know any Lao or Thai programmers. At all. I know they are out there, but I'm not personally acquainted with any. I have casual acquaintance with a few who have dabbled in FoxPro, but they certainly did not do this for a living. I'm also aware that some universities nearby teach Java. Not being one of their students, I have no idea what else they might teach--probably they teach C++, Visual.NET, and perhaps Python? I would be highly surprised to find a Thai programmer of Perl, much less a Thai course in it. (I know several foreigners, however, who will be quite interested in my Thai module--and I would like for Thais themselves to have more tools that would interest them in Perl.)

        This might shock you, but Windows XP is still in common use around here. Windows 7 is likely more common by now, but it should also be understood that I am not personally aware of a single Thai computer that I could confidently say runs an authentic (licensed) copy of Windows. It is not uncommon here to see a PowerPoint presentation before an audience interrupted by a message saying that the copy of Windows is not registered. People on this economy cannot generally afford genuine copies of Windows. Mind, I am not living in Bangkok where many more affluent people live.

        You might walk into a school computer classroom in some places here and see desktop computers with floppy drives in them. In the more urban areas, you would not likely see this--but most of Thailand is rural. Sometimes their computer classrooms get stocked by the hand-me-downs of other schools--which are used until they can no longer be repaired. For both technical and student-management reasons, these computers may have no access to internet. The students' computer training in one school I visited last month consisted of learning the Windows Paint software--drawing pictures with it, and none of the computers in the classroom, except for that of the teacher, had internet access.

        Blessings,

        ~Polyglot~