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

RE: Sealed domain question


> -----Original Message-----
> From: owner-info-dylan@harlequin.co.uk
> [mailto:owner-info-dylan@harlequin.co.uk]On Behalf Of Chris Double
> Sent: Monday, July 12, 1999 6:34 AM
> To: info-dylan@harlequin.co.uk
> Subject: Sealed domain question
> 
> 
> If in a library I have the following definitions:
> 
>   define open abstract class <base> (<object>) 
>   end class <base>;
>  
>   define class <derived> (<base>)
>   end class <derived>;
> 
>   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) => ()
>     // do something
>   end method initialize;
> 
> 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?

It has to be, because your new method changes the applicable methods for the domain initialize (<derived>), which by sealing you declared you weren't going to do.  (Even if you _know_ that initialize on <derived> never calls next-method, the rules of sealing do not require the compiler to make that inference -- the compiler bases optimization on sealed domains on the assumption that the applicable methods of a sealed domain are static.)

If you don't mean for your initialize method on <base> to affect the initialization of <derived>, then you can structure your classes differently (use a subclass of base in your "another" library).  If you do mean for your initialize method on <base> to affect the initialization of <derived> then you can't seal that domain.