develooper Front page | perl.perl5.porters | Postings from July 2009

Re: %^H (was Re: Coring Variable::Magic / autodie fights with string eval in Perl 5.10.x)

Thread Previous | Thread Next
Nicholas Clark
July 9, 2009 03:49
Re: %^H (was Re: Coring Variable::Magic / autodie fights with string eval in Perl 5.10.x)
Message ID:
On Tue, Jul 07, 2009 at 03:49:25PM +0200, Vincent Pit wrote:
> > Code relying on ANYTHING in %^H in 5.8.x is broken and wrong.
> >
> > I can't see how the documentation could be any clearer than the above.
> > This isn't a philosophical position that we should have "rigidly defined
> > areas of doubt and uncertainty". It's a simple practical problem.
> >
> > Perl 5 is pretty bloody hard to support right now. We try hard not to break
> > stuff that is documented as behaving in some fashion, and stuff that is
> > ambiguous in its documented behaviour.
> >
> > It will be impossible to do anything, if people come to expect that even
> > the parts that are documented as "keep off. may change without warning"
> > don't change.
> >   
> I don't think anyone that has used this undocumented behaviour is
> expecting it to be carved in stone (or at least, I'm not - I won't nag
> when it'll break). Having an official hook is definitely the solution,
> but there's also a lot of older perls in the nature and it's good to
> backport them the feature when it's possible and not too far fetched,
> even with a few caveats (as long as they are documented).

Yes, I agree with nearly all of this.

Except "I don't think anyone that has used this undocumented behaviour"

I don't think that anyone who has *directly* used this.

But people write things that are useful, and put them on CPAN. Which is good.
The people who upload it know what they are doing, and (hopefully) write the
caveats in too.

But then someone skims the synopsis on CPAN, decides that this is the
solution, and uses it. Without realising. Maybe *they* write a module, and
upload that.

And one or two steps later, the big warning "this is fragile and may break"
has become laundered away. And it's being used in production code by people
who have no clue what fragility they are relying on.

And then I upload a new version of perl to CPAN.
And those people test it.
And something breaks.
And they blame *me*, for releasing a broken perl.

OK, it's not me now. But it used to be. And I still take is as a personal
(character) assassination risk, all these booby-traps people are creating.

*This* is why I want to get to "supported, documented APIs", and "private",
and no fuzzy bit in the middle of "I know, I get to keep both pieces if this
breaks". That fuzzy bit in the middle creates a minefield.

> But this definitely has a negative impact on the core development. When
> the workaround just "works well enough", it's not that compelling to
> contribute a complete new implementation, especially when you know that
> your module will need to keep the workaround anyway, while your users
> upgrade their perl.

But you don't know this. You're making an assumption.

Existing perl releases don't change. That's fine.

But you can't predict the future. So you need to get your technical debt
paid off, before the pumpking suddenly and accidentally calls it in,
and bankrupts you.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About