[Prev][Next][Index][Thread]

Re: Sealed domain question

Chris Double wrote:
> 
> If in a library I have the following definitions: [abbreviated:]
> 
>   define open abstract class <base> (<object>) end;
>   define class <derived> (<base>) end;
> 
>   define sealed domain make(singleton(<derived>));
>   define sealed domain initialize(<derived>);
> 
> The module in this library exports <base> and <derived>.
> 
> In another library which uses the above module I try:
> 
>   define method initialize( o :: <base>, #key) => () /* ... */ end;
> 
> With Harlequin Dylan I get a sealed domain error:
> 
>   "This method on initialize cannot be added because it is in a domain
>    declared sealed in library x."
> 
> I know 'initialize' is a sideways definition and is not necessarily
> good style but this structure comes up in some code I'm trying to
> compile with Harlequin Dylan. Should it be a sealed domain violation
> if <base> is open and unsealed?

I'm not always the world's best language lawyer but I think that in this
instance HD is right.  Intuitively, the method you're trying to add
would change the behaviour of initialize for instances of <derived>;
pragmatically, this might disrupt optimisations made under the
assumption of sealing (e.g., inlining the call to initialize).

>From the DRM (Ch.9, section "Define Sealed Domain"), constraint 1 says

  A define sealed domain definition in a library L for a generic
  function G with types T1...Tn imposes the following constraints on
  programs:

  1. A method M that is congruent to G and that is not an explicitly 
     known method in L may be added to G only if at least one of the
     specializers for M is disjoint from the corresponding T.

Here the type in the sealing is T_1, <derived> and the corresponding
specialiser in your method M is <base>, which is not disjoint from
<derived>.

Hope that helps,

Hugh G. Greene.
Follow-Ups: References: