develooper Front page | perl.perl5.porters | Postings from June 2013

Re: [perl #118653] [PATCH] Move prototype validation to a separatefunction / stop munging whitespace on parse

Thread Previous
Peter Martini
June 28, 2013 11:44
Re: [perl #118653] [PATCH] Move prototype validation to a separatefunction / stop munging whitespace on parse
Message ID:
On Fri, Jun 28, 2013 at 1:15 AM, Brian Fraser <> wrote:
> On Thu, Jun 27, 2013 at 11:43 PM, Peter Martini <>
> 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: >
>> This is a bug report for perl from
>> -----------------------------------------------------------------
>> 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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About