perlbug-comment at perl
Aug 4, 2012, 6:33 AM
Post #1 of 1
(40 views)
Permalink
|
|
[perl #43248] utf8 encoding and the -i switch
|
|
On Sat Aug 04 02:16:19 2012, aristotle wrote:
> * Ricardo Signes <perl.p5p [at] rjbs> [2012-08-03 21:25]:
> > * Aristotle Pagaltzis <pagaltzis [at] gmx> [2012-08-03T14:43:38]
> > > * Ricardo Signes <perl.p5p [at] rjbs> [2012-07-24 03:55]:
> > > > Let us begin the process of deprecating and ejecting
> > > > [encoding.pm], shall we?
> > >
> > > What does that really entail, anything more than a `use deprecate`?
> >
> > It's dual-life, CPAN upstream, and part of Encode. So we lobby Dan
> > Kogai.
>
> Hmm, so what does it *mean* to deprecate an upstream-CPAN module? Does
> deprecate.pm work with already-dual-life modules? I think not – or am
> I misinformed?
>
> I guess as far as Encode itself is concerned, deprecating encoding.pm
> just means splitting it out into a separate distribution, fiddling the
> docs, and you’re done.
>
> But what then does that mean for core perl? Do p5p just go “oh you miss
> that? Well upstream split it out so it‘s no longer shipped with perl”
> and give a shrug? I guess the newly-created distro for encoding.pm has
> to be added to the list of things the core includes… hmm, logically then
> deprecate.pm must work for already-dual-life modules because how else
> can it be used for the transition period of once-core-only modules? So,
> then it would be added to encoding.pm inside its new distribution, which
> core perl adds just so it can remove it right after the following stable
> release.
>
> Yes?
>
> (Is this process written up anywhere? If not, I may be volunteering
> myself to write a doc patch that once it is all clarified… Where? The
> deprecate.pm POD seems the most likely choice. Probably there should
> then also exist a pointer to it somewhere in the pile of perl*.pod or
> maybe inside Porting. Where?)
I’m not sure that anyone knows the answers to these questions. But you
sound as though you are on the right track. :-)
--
Father Chrysostomos
|
