Front page | perl.perl5.porters |
Postings from July 2009
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 ClarkThread Previous | Thread Next