Re: Possible bug with re-export, :select and GOOPS accessors?!

[Marius Vollmer]

Thien-Thi Nguyen <address@hidden> writes:

>    From: Marius Vollmer <address@hidden>
>    Date: 06 Sep 2001 02:02:38 +0200
> 
>    Yes, I tend to agree, but I also think that their is a significant
>    difference between selecting from the exported set, or selecting from
>    all definitions of a module, thereby violating the module barrier.
>    this kind of thing should be possible, but it should also be visually
>    explicit.
> 
>    I.e., I'd say that `:select' only looks into the set of exported
>    definitions, and `:select-internal' looks into the module itself.
> 
>    Agreed?
> 
> kind of, sort of, maybe.  the crux of the matter is how much weight one
> gives to the "export" concept.  if you think of it as a barrier, then it
> is wise to be explicit when overcoming that barrier.  if you think of it
> as a suggestion, then whether or not you heed that suggestion need not
> be formally expressed.  [insert Erik Naggum quote re C++ / trust, here.]
> i tend towards the latter viewpoint but can understand the former.

I like to see it as a barrier, not so much as to _prevent_ people from
`violating' it, but to clearly state that the module implementor feels
responsible to keep the exported interface relatively stable.  It's
the `service contract' that the module implementor is offering.  When
you reach around the officially exported interface (which ought to be
possible in a non-obscure way), the user takes on the responsibility
when something goes wrong.

As an example, consider a module that maintains a small database and
offers functions for inserting stuff into it, and retrieving on a key.
There is a user of that module, and that user discovers that it not
only needs to retrieve on a key, but also wants to find all data base
entries that fulfill a certain predicate.  The module does not offer
this functionality, but the user knows that internally the module uses
an alist for storing the data.  The module doesn't want you to know
about this, as it wants to reserve the right to change that internal
representation.  The user nevertheless routes around the (restricting)
interface of the module and directly touches the alist.  That is OK.
For example, the user might have submitted a patch to the module that
provides the functionality it needs, but also wants to provide that
functionality immediatly, for people who do not have the new data base
module already.

However, the user should state clearly that it is now using intimate
knowledge about the implementation of the data base module, and it is
prepared to be held responsible when something breaks because of that.
That's why I prefer an explicit way to access internal definitions of
modules, like the `::' of CL compared to the normal `:'.