Sealed domain question 
Author Message
 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?

Chris.



Fri, 28 Dec 2001 03:00:00 GMT  
 Sealed domain question

Quote:

> 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.



Fri, 28 Dec 2001 03:00:00 GMT  
 Sealed domain question

Quote:

> 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 think that this error message is probably less than clear.  The
following is just IMHO, but...

You should be able to add an initialize method on <base>.  What I think
the actual problem is is that your initialize method is also the most
applicable method for <derived>, and that is a no-no.

Try making an initialize(<derived>) method in the library and I think that
should fix it.

The *interesting* thing is what happens if that initialize(<derived>)
method calls next-method()?  Will it use the method on <object>, or will
it use the method on <base> that you added in another library.  I think it
should always use the one on <base> -- since the comiler knows that domain
is open it shouldn't prematurely optomise the call to next-method().

-- Bruce



Sat, 29 Dec 2001 03:00:00 GMT  
 Sealed domain question

Quote:

> 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>;

Ahh, I see now. That makes sense. Thanks for the explanation!

Chris.



Sat, 29 Dec 2001 03:00:00 GMT  
 Sealed domain question

Quote:
> -----Original Message-----


> Sent: Monday, July 12, 1999 6:34 AM

> 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.



Sat, 29 Dec 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Singletons and Sealed Domains

2. Sealed Domain Errata?

3. Sealed Domain Errata?

4. Time domain to frequency domain...and back again

5. convert time domain to frequency domain

6. public domain prolog for apollo domain

7. ForSale: Clipper 5.2 sealed in Box - Best offer!

8. Sealed as Source Annotation

9. Why are head and tail completely sealed?

10. singletons and sealed classes

 

 
Powered by phpBB® Forum Software