Comments on: Testing the Clojure way

By: nonuby

nonuby — Wed, 06 Jun 2012 02:35:16 +0000

Makes good sense to me (ex c# dev, same alt .net bullshit), I kind of knew you would hit on redefs before i got to that part, I just wanted to validate my own intent to use redefs.

By: Chris "Jesdisciple"

Chris "Jesdisciple" — Wed, 14 Mar 2012 00:22:50 +0000

I’ve been thinking further on this, and I’ll now argue somewhat in the opposite direction…

When I first commented on this post, I noticed that dynamically changing another program, and allowing that to happen, are similar to contributions to FOSS projects. Only, instead of the source taking on a life of its own, the runtime does. And typically, when a program is being dynamically modified, its source is also available (and interpreted or JIT-compiled).

So which is better? Surely there are use cases where each one is more optimal than the other, but I’m thinking modifying the original source, though it might take more work, will generally have a better result. Dynamically modifying a dependency seems more likely to be a quick-and-dirty solution than a result of diligent consideration.

The library-user isn’t likely to totally *break* your program; they’ll make sure it still works for their target use-case. But they might introduce inefficiency or make one piece of your library incompatible with another piece. And then 5 months later their application’s requirements change and they (or their replacement/s) trigger the bug they made.

Conclusion: Dynamic modifications might be useful (though I can’t think of any cases at the moment) but should be written with appropriate fear and trembling. Perhaps the language should put up a bit of a fight to make sure the user really wants to do it.

By: newcome

newcome — Tue, 13 Mar 2012 03:55:56 +0000

I see what you mean. I actually used to lament the fact that most of the .NET framework makes everything sealed by default and that methods are not virtual by default like they are in Java. Somehow this seemed different since there was still no possibility that you’d have a private method overridden.

And yet, somehow in Javascript I’m just fine with the fact that someone can replace the implementation of Array.join() if they want to.

Maybe it’s a matter of expectations, and I just need to get used to this new environment?

By: Chris "Jesdisciple"

Chris "Jesdisciple" — Tue, 13 Mar 2012 02:27:51 +0000

“It is kind of unsettling to think that any code you write might be overridden later from above without your knowing[.]”

Exactly what is the problem with that? Python goes so far as to deem that quality of programs as generally desired. A program, by default, works the way the programmer thought it should work. But the user of your library, or anyone else who might know details of your code’s internals, has broad powers to change it. And that’s a good thing, because they have a better idea what the application is supposed to do. If their changes break your program, that’s their fault and not a flaw of their ability to change your program.

Obviously this is a bad thing in security-sensitive applications (see: XSS), but otherwise I fail to see the problem.