in reply to Re: Action at a great distance
in thread Action at a great distance

You're trying too hard, IMO. 
my @copy_args;
foreach( @callback ) {
    local $_ = $_;
    $_->( @copy_args = @args );
}

[download]

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^2: Action at a great distance
by stvn (Monsignor) on Mar 20, 2004 at 14:38 UTC

    Maybe, but TIMTOWTDI. Your code solves the problem for sure, my code assumes that everyone is out to get me, and that nothing is safe. But if you read my post, I suggested that code if the sub refs in @callbacks we "untrusted", not a just a solution to the problem. But again, TIMTOWTDI, and my way is certainly the more paranoid way.

    - stvn
[reply]
[d/l]
      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. Unless you don't trust yourself, which is why we use strictures and friends. However, that's an entirely different issue, not paranoia. Perl is not a language for the paranoid, anyway.

      Makeshifts last the longest.

[reply]
        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]
        Is this not tampering? Your statement is correct in a copy-by-value world, but not in a copy-by-reference world.

        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.

        -stvn
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom