Re: access to subprogram disciminants

[tmoran@bix.com]

You asked for the underlying reason and I answered in terms of
code, but I should have said more basically "to move errors from
run time to compile time".    e.g.
  main_window, go_button:HANDLE;
  ...
  go_button:=CreateWindow("button", ... , main_window, ... );
allows one to write code creating a button before creating its
parent window, causing a run time error.  But
  main_window:aliased frame_windows(initial_width=> ...
  go_button:buttons(parent=>main_window'access, ...
where 'frame_windows' is a controlled type whose initialization
procedure creates a window, eliminates the possibility of that
run time error.  If the coder declares go_button before declaring
main_window, the compiler will point out the error.

>What you are trying to accomplish can be done using normal record
>*components*, initialized as a result of calling a function
>or procedure.  In other OOP's, such a function would often be called
>a "constructor," but in Ada, you can just use normal functions or
>procedures as "constructors."

  I had thought that 'constructor' in C++ was close to 'procedure
initialize' for an Ada 95 Controlled type.  I also thought that the
only parameters available to procedure 'initialize' were discriminants
or other members of the record structure being initialized.  Further,
the compiler will insist that values be supplied for (non-default
valued) discriminants, whereas I can't get the compiler to enforce a
requirement for *any* values for the rest of the record components.
Am I mistaken?

>Don't try to make all of these "parameters" into discriminants.
>Just declare them as components of the data type.  Then, a user would
>declare a simple "Frame_Window" or whatever, and initialize it from the
>result of a function call, or by a subsequent procedure call.
  But that function or procedure call might be left out, causing
a run time error.

>If you make all the "parameters" into discriminants, then
>they are always visible to all clients, and you are forced to represent
>them explicitly, rather than perhaps implicitly in some other
>part of the data type.

  If 'frame_windows' is limited then main_window.initial_width, et al,
are read only constants, no?  Since the width of a window may well
change, the current width is clearly stored elsewhere, accessible only
by calling a function
  w:=current_width(main_window);
Hopefully someone coding
  w:=main_window.initial_width;
will realize they are getting the initial, not the current, width.

  I try to think of an Ada compiler not just as a tool to do scut work
like converting code in an HLL to binary, but as a somewhat intelligent
helper guiding me away from error.  Sort of like the difference between
a rod and hangers keeping my clothes off the floor, vs a gentleman's
valet suggesting that a particular tie might not be the best choice
with a particular suit.  So I'm trying to arrange things so the
language and compiler will be as helpful as possible.