Re^11: eval to replace die?

the unreliable part is writing good regular expressions which are not fragile in the face of simple changes to unstructured data.

Ah, but at least it's possible.

It's impossible to do plain string compare that isn't fragile in the face of simple changes. If

    $str eq "..."
[download]

than any change to either of the strings, how minute, will make

    $str ne "..."
[download]

which is, I think, the point BrowserUK is making.

Whenever I write an exception system, I throw constants (or objects with a method returning such constants). Constants I export. So, if I were to change the value of a constant, the code would still run correctly (or at least, the programmer has to do some work to write code that doesn't run correctly on such a change). And if I were to change the name of a constant, there's a very high probability of the code no longer compiling. Then I can write code like:

eval {....; 1} or do {
    given ($@) {
        when ($EXCEPTION1) {...}
        when ($EXCEPTION2) {...}
        default {...}
    }
};
[download]

Comment on Re^11: eval to replace die? Select or Download Code

Replies are listed 'Best First'.
Re^12: eval to replace die? by chromatic (Archbishop) on Oct 04, 2010 at 21:20 UTC
Ah, but at least it's possible. Certainly. It's also possible for me to write a large Haskell program in one go which passes the type checker the first time, but I don't rely on that. It's impossible to do plain string compare that isn't fragile in the face of simple changes. Absolutely. Yet consider how classes and objects give you abstraction possibilities beyond which you can hide internal changes. That is, if you need to change your exception hierarchy in an incompatible way, you have the possibility of maintaining a compatibility layer between the old version (which can give a deprecation warning) and the new version. Bare strings don't give you that possibility. If you use—as I do—an exception system which uses roles to encode specific details about the type of exception then the only exact string comparison is to the name of the role and not any wording of the exception message. At some level in the system, something does have to compare a string to the name of a role yes, but that doesn't rely on any user having to craft the right regular expression which blends future proofing with accuracy. Whenever I write an exception system, I throw constants.... Sure, I've seen that work well. Code which will only compile when it's correct is an advantage in these cases.	[reply]

Replies are listed 'Best First'.

Re^12: eval to replace die?
by chromatic (Archbishop) on Oct 04, 2010 at 21:20 UTC

Ah, but at least it's possible.

Certainly. It's also possible for me to write a large Haskell program in one go which passes the type checker the first time, but I don't rely on that.

It's impossible to do plain string compare that isn't fragile in the face of simple changes.

Absolutely. Yet consider how classes and objects give you abstraction possibilities beyond which you can hide internal changes. That is, if you need to change your exception hierarchy in an incompatible way, you have the possibility of maintaining a compatibility layer between the old version (which can give a deprecation warning) and the new version.

Bare strings don't give you that possibility.

If you use—as I do—an exception system which uses roles to encode specific details about the type of exception then the only exact string comparison is to the name of the role and not any wording of the exception message. At some level in the system, something does have to compare a string to the name of a role yes, but that doesn't rely on any user having to craft the right regular expression which blends future proofing with accuracy.

Whenever I write an exception system, I throw constants....

Sure, I've seen that work well. Code which will only compile when it's correct is an advantage in these cases.

[reply]