In a message dated Wed, 4 Oct 2006, jesse writes:
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote:
The point is that the person writing the program decides which handcuffs or
costumes all of the code has to wear, not the person writing the libraries.
If you want to set a policy for your organization, that's fine. It is just
Not Okay for me or anyone to write a module right now that dictates exactly
the strictness of every program written in the next twenty years that uses
it.
Perhaps I'm misunderstanding what you mean by "person writing the
program" and "person writing the libraries." In fact, I've _gotta_
be. I'd like to be able to put my strictures in a library rather than
forcing them into the main body of a program. Are you saying
you don't want to let people do this?
I read it as "yes, you *can* put strictures on the using code into a
library, though I wouldn't do it and would say that any module that does
so shouldn't be released on CPAN for general use. But even if you can do
that, you *must* always be able to turn the strictures back off."
chromatic, is that a fair paraphrase?
I don't have any problem with that sentiment--if I were you and needed to
enforce some style on other programmers who work with me, I'd just tell
them to use my library and not unuse it. It's a human problem, not a
technical one, if they insist on unusing it by nefarious means.
That philosophy doesn't present any problems with DBC checks, which as I
mentioned before probably have to handled as a program-global flag rather
than as a lexical pragma anyway. (I'm toying with the notion of
"jurisdictions" that packages could subscribe to across which a set of
contracts would be enforceable, allowing them to do DBC while still using
or being used by code out in some other lawless jurisdiction. Code that
doesn't explicitly join some jurisdiction would by default be lawless,
thus living by the philosophy chromatic's espousing. I think that could
be made to work, though jurisdictions would have to be at a package, not
scope, level. I need to think about it more, though.)
Trey
