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

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

Replies are listed 'Best First'.
Re^4: Action at a great distance
by Aristotle (Chancellor) on Mar 20, 2004 at 14:58 UTC
    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.

      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" };
      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
        Consider this:
        my @args = ([1, 2, 3], "hello"); push @callbacks, sub { $_[0]->[0] = "tampered" };
        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.