Front page | perl.perl5.porters |
Postings from January 2012
On Tue, Jan 31, 2012 at 04:02:59PM +0100, demerphq wrote: > On 31 January 2012 16:00, Nicholas Clark <nick@ccl4.org> wrote: > > On Mon, Jan 30, 2012 at 02:22:06PM +0100, demerphq wrote: > > > >> I agree mostly. But I think this a balance issue. We have multiple > >> priorities, and whatever mechanism we choose needs to satisfy as many > >> of those priorities as possible. > >> > >> I think we need to: > >> > >> a) inform the user that their script will break in a future release of Perl. > >> b) do so in a way that ensures a high level of compliance > >> c) do so in a way that ensures a low of level of negative consequences > >> for the user. > >> d) do so in a way that is cost-effective from the point of view of > >> developer investment. > > > > Yes > > > >> I personally think that our current strategy satisfies a, b, and d, > >> but does not at all, in any way, satisfy c. > >> > >> I believe my proposal satisfies c without jeopardizing a b or d. > > > > Yes > > > >> So as long as we don't have an alternative strategy then I believe > >> that what I proposed is a reasonable middle ground. > > > > Not sure how we might go about implementing it. > > Hash of lines + warning message (format or something). I first thought "optree - that's a bugger, that's read only" and then considered that an interpreter-based hash of script filename and line would work. But it still felt hackish. (Even if I decided that people who had used #line directives to have the same line appear more than once were on their own.) I think you're right with using the format string - I'd not thought of that, and it's possible that more than one warning might come from a complex construction at different times. (Given that some of the warnings are run- time based on the data) I suspect that "address of current op" is a cheaper thing to store than "file plus line". That plus format should be good enough. Nicholas ClarkThread Previous | Thread Next