[Openmcl-devel] Package locks?

[Hamilton Link]

On Mar 31, 2004, at 1:35 PM, Peter Seibel wrote:

> Gary Byers <gb at clozure.com> writes:
>
>> On Tue, 30 Mar 2004, Peter Seibel wrote:
>>
>>> Does OpenMCL have anything like Allegro's or CMUCL's package
>>> locking? I.e. something to prevent code outside a package from
>>> mucking with the definitions attached to symbols in the package?
>>
>> No.  At first glance, the idea seems wrong (or maybe more accurately
>> half-right), but that's not an opinion that's based on actually having
>> used them (or having thought about the idea for more than a few 
>> minutes.)
>
> I suspect you're right. Or half-right. ;-) That is, package locks are
> by no means a full solution to all the possible information-hiding and
> keep-other-folks-from-breaking-my-code-from-the-outside problems that
> one might like to solve. That said, they do provide an answer to the
> seemingly reasonable question: how do I keep someone who USE-PACKAGE'd
> my package from inadvertently stomping on a definitions that I care
> about that happens to be on an exported symbol.
>

If the threat of concern is people defunning over your API, you can set 
the kernel-function flags on your API to get the same protection CAR 
and CDR have (the functions for doing so are not exposed, I'm just 
saying there is a mechanism in place that applies to more than car and 
cdr). Gary's point is that this doesn't prevent people who are 
intentionally trying to meddle with your package from doing so, since 
this is essentially a read-time protection rather than a run-time 
protection (and so things like (setf (fdefinition 'foo) #'broken) will 
not be prevented). He and I started talking about what run-time 
protection would look like and how one might declare it (along with a 
more ada-like package declaration, which distinguishes between function 
and value and class visibility rather than just all-of-a-symbol 
visibility), but didn't pursue it very far.

Gary knows more than I do about how to prevent defclass etc. at this 
level, but I suspect an un/lock-package function wouldn't be hard to 
write.

h