Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^4: A DWIM too far?

by BrowserUk (Patriarch)
on Jun 18, 2004 at 03:04 UTC ( #367846=note: print w/replies, xml ) Need Help??


in reply to Re^3: A DWIM too far?
in thread A DWIM too far?

There is a difference.

Most of those permissive behaviours that you describe,and which I mostly relish, are controlled entirely within the auspices of my program!

The destructive behaviour of rename means that I may well be destroying someone else's data, or someone else accidentally or deliberatly destroying mine.

I consider that a fundemental distinction.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^5: A DWIM too far?
by revdiablo (Prior) on Jun 18, 2004 at 04:47 UTC

    It doesn't seem like such a fundamental difference to me. Modifying the wrong hash element in an inhereted object can cause data loss. Changing a global sub (such as you do here) can cause serious problems if not done with care. All the behaviors "within the auspices of [your] program" are not necessarily as limited as you seem to imply. And besides, all the behaviors of an operating system are controlled entirely within the auspices of one computer.

    The difference I see is not fundamental, it is one of likelihood. The chances of problems caused by permissive behavior are less at the application level than the operating system level, but they are still there. As I said before, I like a platform that is as permissive as possible, and that goes for programming langauges as well as operating systems. After all, what is an operating system but another programming platform?

      It doesn't seem like such a fundamental difference to me.

      Then you either haven't taken the time to think before commiting to that opinion, or you simply haven't bothered to consider the possibility that a unix behaviour could possibly be flawed.

      Modifying the wrong hash element in an inhereted object can cause data loss.

      Modifying the wrong hash element is entirely within the control of my application.

      Overwriting or deleting a file created by a different application (or vice versa) is not.

      Changing a global sub (such as you do here) can cause serious problems if not done with care.

      I didn't "do it". I simply reminded someone else how Perl would let them do it, should they choose to.

      And besides, all the behaviors of an operating system are controlled entirely within the auspices of one computer.

      And if the files resides on a network drive or NFS mounted filesystem?

      The difference I see is not fundamental, it is one of likelihood. The chances of problems caused by permissive behavior are less at the application level than the operating system level, but they are still there.

      What makes the difference fundemental is that I can code my application to test for and avoid modifying the wrong hash element.

      To safely rename a file requires that the OS detect and inform me about potential collisions, as any test I code into my application opens a race condition on a multi-tasking system.

      My OS does this at the system API level. The thing that took me by surprise was that the Perl implementation chose to override this.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://367846]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2022-01-25 16:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (67 votes). Check out past polls.

    Notices?