There’s no discussion of domain-level operations.

[simonjwright]

You might need domain-level operations for at least two possible reasons:

• to provide an interface to higher-level domains. This is OK for procedures, but for functions seems a little more tricky; internally, the domain code runs under its dispatcher, and there could be concurrency issues unless the calling domain is using the same dispatcher.
• to support domain setup.

[AlexProudfoot]

I'm trying to use a domain init operation to set up initial instances ...

I'm getting the following report.

gnatmake -p -P Domain_Tests/Air_Traffic_Controller_Test
Compile
   [Ada]          test_air_traffic_controller.adb
   [Ada]          air_traffic_controller.ads
   [Ada]          air_traffic_controller-initialize.adb
air_traffic_controller-initialize.adb:30:07: "Air_Traffic_Controller_Custom_Initialize" is undefined
gprbuild: *** compilation phase failed

On examination of Air_Traffic_Controller.Initialize, I noticed that the procedure was called but not withed.

--------------------------------------------
--  Automatically generated: do not edit  --
--------------------------------------------
pragma Style_Checks (Off);
--  Domain revision: unspecified
--  Extraction date: 13 03 2021, 06:39
--  Extractor: normalize_xmi
--  Normalizer: normalize_xmi
--  Generator: cf-DATE
with Ada.Exceptions;
with ColdFrame.Project.Log_Error;
with Air_Traffic_Controller.Events;
with Air_Traffic_Controller.Control_Zone.CF_Initialize;
with Air_Traffic_Controller.Duty_Station.CF_Initialize;
with Air_Traffic_Controller.On_Duty_Controller.CF_Initialize;
procedure Air_Traffic_Controller.Initialize
  (Dispatcher : ColdFrame.Project.Events.Event_Queue_P := null) is
   use type ColdFrame.Project.Events.Event_Queue_P;
begin
   if not Domain_Initialized then
      Domain_Initializing := True;
      if Dispatcher /= null then
         Events.Dispatcher := Dispatcher;
      else
         Events.Initialize;
      end if;
      if Events.Dispatcher /= null then
         ColdFrame.Project.Events.Add_Reference (Events.Dispatcher);
      end if;
      Air_Traffic_Controller_Custom_Initialize;
      Control_Zone.CF_Initialize;
      Duty_Station.CF_Initialize;
      On_Duty_Controller.CF_Initialize;
      Domain_Initialized := True;
      Domain_Initializing := False;
   end if;
exception
   when E : others =>
      ColdFrame.Project.Log_Error
        (Ada.Exceptions.Exception_Information (E));
      raise;
end Air_Traffic_Controller.Initialize;

Have I omitted part of the setup?

[simonjwright]

Have I omitted part of the setup?

No, that’s the problem.

If you have <<domain {init=Other_Package.Some_Proc}>>, the generated domain initialization procedure will with Other_Package;. But even if you say This_Package.Some_Proc, no Some_Proc spec/dummy body will get generated.

One workround would be as in the attached: create a private null type and declare the initialization procedure in it. That way the type will be invisible to your users, and the procedure will be likewise invisible but will be spec’d in the domain.

Initialisation.uml.zip

[AlexProudfoot]

OK. That worked well. Thanks for the suggestion.

Air_Traffic_Control.uml.zip

[AlexProudfoot]

At this point, it seems like a good idea to check how this looks in the html documentation.

[simonjwright]

Thinking about doing a proper writeup in the Initialization page, I realise that it’s very confusing to have domain initialization (Domain.Initialize) and domain setup called the same thing.

Proposal:

• What’s now indicated by the {init=foo} tagged value on domains be renamed setup
• Remove, or at least deprecate, «init» on class operations

There’s no loss (aside from backward-compatibility) in removing class initialization operations, since the usual usage was to delegate domain setup to one class anyway.

[AlexProudfoot]

Sounds good. Anything that removes implementation/setup clutter from the class diagrams has my vote. IMO, another culprit in this regard is defined <<accessor>> operations. Right now, I’m getting ColdFrame to generate them but I realise that this sacrifices the ability to have private attributes. Maybe we could allow the access type (+/-) of the attribute to control the generation of accessors?

[AlexProudfoot]

Hey Simon. I'm thinking that a domain shutdown procedure, analogous to the domain setup procedure would be useful in some cases. In particular, I'm working on an application which saves the contents of all instances and relationships to a file at shutdown and reloads them at startup as a basic demonstration of persistence. Is this something you could get ColdFrame to provide?