in reply to Perl Safety

If the code-review rule is adopted that nobody touches anyone else's package data, then you have nothing to worry about unless you have people that don't go through code review.

You don't need safety from the compiler. You can get safety implemented as humanware. And if that's not enough, yes, you can do some difficult things with Perl to make it also compiler-enforced, at the expense of clarity and maintainability.

If you're working in a place where you can't trust your fellow hacker, quit.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: Re: Perl Safety
by gaspodethewonderdog (Monk) on Aug 25, 2000 at 19:22 UTC
    Well I am having fun... so no need to quit. Anyway, the situation is basically this:

    several functions that I call return nothing, instead the implicitly set variables $x,$y,$z.

    I am just worried that at some point $x,$y,$z may also at some point include $a which may be something I'm using and need to keep clean myself.

    Does Perl provide any clean way to partition myself from other parts of the program?

[reply]
      Don't call them. Raise a stink. Really.

      In the meantime write wrappers for these functions, in the wrappers call, check the implicit variables, and return them. Then when the code can be fixed, less has to be changed. If you can, localize the variables in your wrapper.

      And "use strict" to be sure you have everything lexically scoped.

      But people like that are a hazard to your code base, nothing more and nothing less.

[reply]
        Actually I have managed to seperate myself from most of the grubby stuff by putting my routines into their own module(s). I've been pushing my employer pretty hard to let me reimplement a lot of this stuff (even so far as to replace all these hacked database (read flat text files) to real databases), yet right now the reality is I have to deal with all the corporate overhead... beauracracy and all... I've had implied to me that fixing these things would be a bad idea (lots of reimplementation???) but more than likely it is somebody wanting to be lazy.

        For now I'm just trying to get one thing fixed at a time... however there is no reason to *not* be paranoid. I have had a few too many problems in the last year with people changing code bases under me without warning to not be worried and as such raise it as a concern.

        Having people rely on your code and when it breaks not knowing where the problem is just stinks. Especially when you had nothing to do with the breaking.

[reply]
      Ugh. So you're telling me you've got bad code? No amount of Perl Safety will help you.

      If $x and $y and $z are in their package, you're safe. If you're telling me you're not using packages, quit, no matter how much fun it is. {grin}

      -- Randal L. Schwartz, Perl hacker

[reply]
        Hrmmm... well the engineer actually put everything in a package, but for some reason has no idea about returning hashes or *something*...

        Actually what scares me mostly about this guy is that he claims he writes faster code in Perl than in C. So either he is a Perl god (which I think I can rule out already) or he is an even worse programmer in C than in Perl.

        Anyway, thanks for the suggestions... I'll just make sure to change my variables over to 'my' and protect myself as best I can.

        Maybe I'll just continue to bug my boss to let me take over this guy's project anyway. Any time I ask him to do something it doesn't get done until it's convenient for *him*... and then it's all 'huzzah I've implemented this amazing feature that I *just* realized our group needed' :P

[reply]

In Section Seekers of Perl Wisdom