[m-dev.] RTTI & breaching the abstraction barrier

[Fergus Henderson]

On 05-Feb-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> This has been bugging me for a while, so I thought I'd mention it.
> 
> The type reflection stuff in std_util allows a programmer to pick
> apart an object whose composition would normally be hidden because
> the object's type is abstract.
> 
> What's worse, it seems that a sneaky programmer can also construct
> objects of the abstract type and place them in circulation.  This
> can cause problems.  For instance, set/1 is an abstract type
> implemented as an ordered list; using construct/3 I can create an
> instance of set/1 that does not satisfy this property.
> 
> Admittedly this would be an odd thing to do, but it is a hole.
> 
> Is this a hole to be plugged (I'd be interested in the mechanism)
> or a necessary evil?  [Disclaimer: I think RTTI is a Good Thing!]

Well, we haven't fully investigate all the repercussions, but
currently we're treating this as a hole to be plugged.

The basic idea is that there will be a builtin type class
`constructable(T)', and `construct/3' will have that type class
constraint.  Although all user-defined types will automatically be
instances of this type class, for abstract data types that instance
declaration won't be exported by default; the user will need to
explicitly declare the instance declaration in the module interface if
other modules are to use it.  Likewise type variables won't be
automatically assumed to satisfy this type class constraint, so
for polymorphic routines, if they make use of it, they will need
to include the type class constraint in their type declaration.

That will break backwards compatibility in a fairly major way, though,
so this is something for V2 of the standard library.

However, in some situations, e.g. for persistence, transparent
distributed programming, etc., it might be necessary to construct
arbitrary types, even those which are not explicitly marked as
`constructible'.  So sometimes it might indeed be a necessary evil.

To solve that, we could also provide an `unsafe_construct', which is
like `construct', but without the type class constraint.  But we'll
mark that routine as `unsafe', which would be a new annotation,
similar in style to the existing `impure' annotations.  Calls to
`unsafe' routines would only be allowed in "trusted" modules.  There
would be an option on the Mercury compiler that would reject any such
calls; this option should be enabled when compiling untrusted code.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------