chromatic wrote:
jesse wrote:
> Ok. So, I think what you're saying is that it's not a matter of "don't let
> people write libraries that add strictures to code that uses those modules"
> but a matter of "perl should always give you enough rope to turn off any
> stricture imposed on you by external code."
>
> Do I have that right?
Yes. You might also add "... or enable further strictures", but that sounds
like what I was trying to say.
Consider the following idea, bearing in mind that chromatic will
probably consider it to be a waste of time and that we shouldn't hold
up the release of p6 in order to develop it even if it's deemed
acceptable:
A 'policy' is a thing which places restrictions on what the programmer
can do. Policies can be named or anonymous. Named policies can be
exported. A module that exports policies is also known as a contract.
As a means of making this easier, a 'contract' trait exists for
modules which applies the 'export' trait to all policies found within.
Proper use of policies is to define them in a contract, then import
them into the appropriate lexical scope with 'use' - this lets you
deport them later (using 'no') when you no longer want their
restrictions.
Example:
module strict is contract;
policy vars { ... }; # Handwavium for the definition of a policy
named 'vars'.
...
# EOF
# somewhere in another module:
use strict; # imposes all of strict's policies on this lexical scope.
...
{
no strict <vars>; # rescinds the 'vars' policy within this codeblock.
...
}
AFAICT, this can't be done using the current toolkit, as there's
nothing akin to policy definition. Compared to that, adding a
'contract' trait is trivial.
Alternatively, contracts could be promoted to the same level as
classes and modules, with a keyword of their own and an additional
requirement that policy definition must occur within a contract.
You'd still make use of a policy by importing it from a contract where
appropriate, and all that would change in the above example would be
that the first line would change to "contract strict;" Another
benefit of this approach is that it might be possible to say that a
contract is exempt from its own policies; you have to import policies
from a contract in order for them to take effect. This keeps contract
writers from having to abide by the policies that they're writing
while they write them.
--
Jonathan "Dataweaver" Lang
