Logical constants

Logical constants

[Victor Porton]

I pass a private type T (whose full type is a record) containing a Handle to 
a subprogram.

(In fact, a handle is a pointer to a C struct.)

All such subprograms can be written as subprograms with "in" mode for T, 
because they do not modify the handle.

But some of these programs logically modify the corresponding C object 
(without modifying the handle itself, they may modify the struct the handle 
points to).

Should I pass T arguments to such subprograms in "in out" mode? To use "in" 
only is allowed by the language rules, but logically them are "in out".

What are the arguments for using either "in" or "in out" in this case?

-- 
Victor Porton - http://portonvictor.org

Re: Logical constants

[Dmitry A. Kazakov]

On 2017-09-29 20:12, Victor Porton wrote:
> I pass a private type T (whose full type is a record) containing a Handle to
> a subprogram.
> 
> (In fact, a handle is a pointer to a C struct.)
> 
> All such subprograms can be written as subprograms with "in" mode for T,
> because they do not modify the handle.
> 
> But some of these programs logically modify the corresponding C object
> (without modifying the handle itself, they may modify the struct the handle
> points to).
> 
> Should I pass T arguments to such subprograms in "in out" mode? To use "in"
> only is allowed by the language rules, but logically them are "in out".
> 
> What are the arguments for using either "in" or "in out" in this case?

It is undecided.

1. A "transitive" approach is that the mode of a proxy object must 
reflect the mode of the target.

2. A "non-transitive" one is that modes of two objects are separate.

E.g. Ada's access types take the second approach. A pointer can be 
constant and target mutable and conversely.

Arguably the first one should be chosen when the proxy hides/represents 
the target and the second when both types are independently visible.

But Ada.Text_IO still takes the second approach. Ada.Text_IO.Create has 
in out File_Type. Ada.Text_IO.Put has in File_Type, though the target is 
clearly invisible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Logical constants

[Victor Porton]

Dmitry A. Kazakov wrote:

> On 2017-09-29 20:12, Victor Porton wrote:
>> I pass a private type T (whose full type is a record) containing a Handle
>> to a subprogram.
>> 
>> (In fact, a handle is a pointer to a C struct.)
>> 
>> All such subprograms can be written as subprograms with "in" mode for T,
>> because they do not modify the handle.
>> 
>> But some of these programs logically modify the corresponding C object
>> (without modifying the handle itself, they may modify the struct the
>> handle points to).
>> 
>> Should I pass T arguments to such subprograms in "in out" mode? To use
>> "in" only is allowed by the language rules, but logically them are "in
>> out".
>> 
>> What are the arguments for using either "in" or "in out" in this case?
> 
> It is undecided.
> 
> 1. A "transitive" approach is that the mode of a proxy object must
> reflect the mode of the target.
> 
> 2. A "non-transitive" one is that modes of two objects are separate.
> 
> E.g. Ada's access types take the second approach. A pointer can be
> constant and target mutable and conversely.
> 
> Arguably the first one should be chosen when the proxy hides/represents
> the target and the second when both types are independently visible.
> 
> But Ada.Text_IO still takes the second approach. Ada.Text_IO.Create has
> in out File_Type. Ada.Text_IO.Put has in File_Type, though the target is
> clearly invisible.

What should be argument mode for an object for which a handler (of some kind 
of event or some callback) is set?

Set_Handler_*(Object, ...);

Currently I am thinking about

procedure Set_BNode_ID_Handler
  (World: Raptor_World_Type_Without_Finalize'Class;
   Handler: access BNode_ID_Handler'Class);

World is a main object of a library, to keep there user settings.

Handler is a generator of a blank node ID (that is a unique string starting 
from underscore, like "_ax123").

Should Set_BNode_ID_Handler be considered as modifying World object?

Set_BNode_ID_Handler modifies user settings, World is user-settings, so it 
should be considered as a modifying subprogram and World argument should be 
change to "in out" rather than "in" mode, do you agree?

-- 
Victor Porton - http://portonvictor.org

Re: Logical constants

[Dmitry A. Kazakov]

On 2017-10-02 21:07, Victor Porton wrote:

> What should be argument mode for an object for which a handler (of some kind
> of event or some callback) is set?
> 
> Set_Handler_*(Object, ...);
> 
> Currently I am thinking about
> 
> procedure Set_BNode_ID_Handler
>    (World: Raptor_World_Type_Without_Finalize'Class;
>     Handler: access BNode_ID_Handler'Class);
> 
> World is a main object of a library, to keep there user settings.
> 
> Handler is a generator of a blank node ID (that is a unique string starting
> from underscore, like "_ax123").
> 
> Should Set_BNode_ID_Handler be considered as modifying World object?

Likely so.

One of two arguments should be dispatching. If handler is a proxy object 
it should be passed without access and copied inside. If handler is not 
a proxy then it should be "not null access", unless null value is used 
to remove the handler.

Now if all handlers are siblings then it goes as:

    type Abstract_Handler is ... abstract ...;
    procedure Set
              (  Handler : not null access Abstract_Handler;
                 World   : in out ...'Class
              )  is abstract;

    type BNode_Handler is new Abstract_Handler with ...;
    overriding
       procedure Set
                 (  Handler : not null access BNode_Handler;
                    World   : in out ...'Class
                 );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de