On Fri, Jun 28, 2013 at 1:15 AM, Brian Fraser <fraserbn@gmail.com> wrote: > On Thu, Jun 27, 2013 at 11:43 PM, Peter Martini <perlbug-followup@perl.org> > wrote: >> >> # New Ticket Created by Peter Martini >> # Please include the string: [perl #118653] >> # in the subject line of all future correspondence about this issue. >> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=118653 > >> >> >> This is a bug report for perl from petercmartini@gmail.com >> ----------------------------------------------------------------- >> >> Prototypes defined inline currently have spaces removed for no other >> reason than to simplify processing. This leads to inconsistencies >> between defining a prototype inline and attaching it after the fact. >> >> Also, since the logic for generating warnings is only stored in the >> tokenizer itself, if something like set_prototype or a prototype >> attribute wanted to do illegalproto warnings, it would have to >> duplicate that logic. Moving the code into a separate function allow >> for code reuse for other mechanisms of setting the prototype. >> >> If this patch is accepted, please apply and hold this ticket open; >> perldelta will need to be updated, and I'm not sure of how that should >> be done, and in the meantime I can base a couple of other illegal >> proto warnings fixed off of the new function. > > > Awesome, this had been on my todo list for a long time. > > However, I'm not so sure about making this function public, since we would > be committing to an interface that may or may not make sense, so +-1 for > this patch (for example, I think validating a proto & emitting warnings > ought to be two different things, but this function has them in one). If > this was two patches, one that split the checks out and one that made the > new function public, then +1 to the former. > I think you made the same points as Nick, so I hope my reply to him should suffice, but I also forgot to mention: One of the reasons I like having the warning built in to the function directly (although you're right, having it at least controllable by a parameter is a must) is that it makes easier to potentially to localize error messages / warnings. But that's just an idle thought, and not something I've looked into, or plan to :-)Thread Previous