Considering it is impossible for the callbacks to tamper with their caller's data using my solution, I don't see why one needs to try even harder.

Consider this:

my @args = ([1, 2, 3], "hello");
push @callbacks, sub { $_[0]->[0] = "tampered" };
[download]

Unless you don't trust yourself, which is why we use strictures and friends.

In a large project, with many developers working with one another code/modules, the ability to rely on trust or friendship is a not always a reality or a good idea. And even if its your very best friend from childhood whom you would trust with your life, why leave a door open for him/her to make a small mistake and cause a bug as insidious as the OP's to crop up? Sure if you are building a program whose required degree of reliability is minimal, then go for it. But if someone is paying you money to build software for them, they have a right to expect that your software will do as much as possible to assure the correctness of all data being processed.

As for suggestion of reliance on "strictures" (and I assume you mean use strict), it would make no difference if you code is correct perl code, but incorrect for the task at hand. Strictures are nice, but they are not a bullet proof vest.

Perl is not a language for the paranoid, anyway.

Perl is a langauge which embraces diversity. Perl is a swiss-army chainsaw. Perl is a langauge where "there is more than one way to do it", and that includes the paranoid way. I do not think you should make sweeping generalizations like that, to each his/her own, and you have no right to tell me different. As far as I am concerned, you are free to code as you like, and I will never tell you different.

Consider this:

my @args = ([1, 2, 3], "hello");
push @callbacks, sub { $_[0]->[0] = "tampered" };
[download]

Is this not tampering? Your statement is correct in a copy-by-value world, but not in a copy-by-reference world.

Yes, so? You have not been any more paranoid than me. Your code does not make a deep copy of @args so your validate() has no chance of detecting that sort of tampering either.

Btw, "strictures^[1] and friends" means "strictures and other stuff like strictures", not "use strictures and have co-developers you are friends with".

I do not think you should make sweeping generalizations like that, to each his/her own, and you have no right to tell me different.

You are confusing a statement of fact for an opinion on style. There are two reasons to add validation code like yours, and in neither case does it make sense.

The first is when the data examined is user input. But if it's code that you have been fed by a user, such as would be the case in this example, you have lost right away. Even if you made a deep copy, someone determined enough could use PadWalker to tamper with your original @args as well as their copy and you'd have no way to detect that. If it runs inside your Perl interpreter, you better be able to trust it.

The other is if you want to guard against your own mistakes — the same reason to rely on strictures, enable warnings, use three-argument open(), and so on. But what does your validation code help? Look at it. Now look at the code I wrote. Which one is easier to maintain? In which one would bugs be easier to spot?

^[1] Larry's term for the rules enforced by strict.

Makeshifts last the longest.

Let me state for the record:
I wrote that snippet as an example of testing possibly unknown and untrusted code and data pre and post the calling of the callback routine, nothing more. The OP supplied very little information, and i was working with what I had.

Your code does not make a deep copy of @args so your validate() has no chance of detecting that sort of tampering either.

The lack of a deep copy issue, you correctly pointed out in here and I responded to you in here. If I were to actually write this code for a real application, I would know alot more about the data I was dealing with and from where the callback subs were coming. Given that information I would likely have written a @arg copying routine that was appropriate. I disagree with you though that validate would be useless without a deep copy, I purposly left validate undefined, as again, I knew nothing about what kind of data the OP was dealing with. validate could easily be effective without the deep-copy though, but until I have more info on the type of data in @args neither of us can say anything for sure.

Btw, "strictures1 and friends" means "strictures and other stuff like strictures", not "use strictures and have co-developers you are friends with".

That makes more sense, I thought it a little silly you would group "strictures" and "other people" together, but hey, I am not a mind reader.

You are confusing a statement of fact for an opinion on style.

Well, I apologize if I did, but when i see something like this:

Perl is not a language for the paranoid, anyway.

I read it as a statement of fact (which I obviously know is really an opinion), and not so much a statement of an opinion. If you only meant it as an opinion on style, you should have declared it as such, but this is kinda nit-picking so I will drop it.

There are two reasons to add validation code like yours, and in neither case does it make sense.

I disagree, neither of your reasons were really the ones I was thinking of. Your first point, re: user input is correct, a determined user could tamper with alot of things, and there it little we can do to prevent that. But that is a whole other issue, and my code was not an attempt to address that. Your second point re: guarding against my own mistakes is partially what I had in mind, although not just my mistakes, but the mistakes of others as well. Most of what I was trying to illustrate is explained in here, and this post. And once again I want to remind you that the OP supplied little or no information about the code at all, so alot of what I was doing was guessing. It was not real code, just an example.

Look at it. Now look at the code I wrote. Which one is easier to maintain? In which one would bugs be easier to spot

As to which is more maintainable, I beleive mine is more explict as to my intentions, yours could be made as explicit with the addition of comments, so I think this is a style/taste issue. As for the bugs, well I will not debate with you that the more lines of code, the more potential bugs, but my code is not that complex, so I think that it is somewhat irrelevant in such a small context. Besides if validation were to be made a requirement of this code, then we would likely be approaching a similar code-size anyway, and hence the same potential for bugs.

Which code is "better", IMO is largely a matter of taste and personal style (at least in this case). I find no faults in your code, it works as promised. But it is not my taste, or my style. To each their own, cause TIMTOWTDI.

But what does your validation code help?

NOTE: What follows is largly opinion, take it or leave it, your choice.

In your code:
perl will die if your callback is not a subroutine ref and display the standard message about what happened.

In my code:
the fact the callback is not a subroutine ref causes perl to die with my error message (and if i were really doing this) an exception object containing a full stack trace. I control the situation, thats what i like about it. My exception handling code (and possible recovery code) can deal with this in a targeted way. Sure its a few more lines to maintain, but to me being explicit in my requirements for the callbacks helps to ensure that others who might follow me know for sure what I expect to get from @callbacks and what I expect to be done if it fails to meet that criteria. Yes, your code makes explicit that members of @callbacks are to be subroutines with this code $_->(), but you leave the "what happens next" up for debate. Again, no one way is better than the other, its a matter of style IMO.

In your code:
No post-callback validation is done.

In my code:
After a callback in run, the @args are checked. Why? I don't know, it depends upon what is in @args and what this code is for. The need for this kind of validation is clearly debatable, but it makes no sense to do so unless we know alot more about what this code is all for.

Aristotle, I respect your opinions, and think nothing ill of your code. But its just not how I would do it, and clearly, you would not do it my way. We can debate the minutia of this forever, but the fact is, there just aren't really enough details about the code and its data to make that debate worth while (IMO of course). I propose to let this issue drop in this node. If you like, we can start another node about the the pros and cons of paranoid code, and I would be happy to discuss this more if you like, just in a different context.

-stvn