develooper Front page | perl.perl5.porters | Postings from September 2021

Re: Pre-RFC: Rename SVf_UTF8 et al.

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
September 15, 2021 20:02
Subject:
Re: Pre-RFC: Rename SVf_UTF8 et al.
Message ID:
DCA6E3E6-EFC6-4130-A2E0-80044530D3D2@felipegasper.com

> On Sep 3, 2021, at 10:24 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
> 
> On Wed, 18 Aug 2021 13:18:34 -0400
> Felipe Gasper <felipe@felipegasper.com> wrote:
> 
>> PROPOSAL: Rename the following identifiers in code and documentation,
>> leaving macros for the old ones as aliases:
>> - SVf_UTF8        -> SVf_PVUPGRADED
>> - SvUTF8          -> Sv_PVUPGRADED
>> - SvUTF8_on       -> Sv_PVUPGRADED_on
>> - SvUTF8_off      -> Sv_PVUPGRADED_off
>> - SvPOK_only_UTF8 -> SvPOK_only_UPGRADED
> 
> This got briefly mentioned as a side-comment on PSC today.
> 
> Thoughts are "What about WIDE"? As in
> 
>  SVf_WIDE (though really I'd want to call that SVppv_WIDE)
>  SvWIDE
>  SvWIDE_on
>  etc...

Now that this thread seems to have “settled” a bit, I wonder where this idea stands in the general mindset:


a) Good idea, worth the overhead of renaming a long-established identifier.

b) Good idea, but *not* worth that overhead.

c) Bad idea; the status quo is better than either of the proposed renames.

d) … some other stance?


To recap, arguments in favour include:

1) More accurate: “wide” encoding allows things that UTF-8 proper forbids, so calling it “UTF8” isn’t quite right.

2) The rename discourages thinking of the flag as indicating a “UTF-8 string”--a widely-held misconception.

3) The upheaval would highlight how the abstraction *should* work and hopefully right some lingering misconceptions out and about.


Thank you!


-FG
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About