Re: Operation can be dispatching in only one type

[Adam Beneschan <adam@irvine.com>]

On Nov 13, 12:12 pm, xorque <xorquew...@googlemail.com> wrote:
> Hello.
>
> I'm trying to write an archive/directory abstraction in a similar vein
> to PhysicsFS
> but am at a bit of a loss as to how to design the archiver interface:
>
> with Path;
>
> package Archiver is
>
>   type Archiver_t              is abstract tagged limited private;
>   type Archiver_Class_Access_t is access Archiver_t'Class;
>
>   procedure Init
>     (Archiver : out Archiver_t) is abstract;
>
>   function Can_Mount
>     (Archiver : in Archiver_t;
>      Path     : in Path.Real_t) return Boolean is abstract;
>
>   type File_t              is abstract tagged limited private;
>   type File_Class_Access_t is access File_t'Class;
>
>   procedure Open
>     (Archiver : in     Archiver_t;
>      Path     : in     Path.Virtual_t;
>      File     :    out File_t) is abstract;
>
>   procedure Close
>     (File : in out File_t) is abstract;
>
> private
>
>   type Archiver_t is abstract tagged limited null record;
>
>   type File_t is abstract tagged limited null record;
>
> end Archiver;
>
> The idea of the above is that the main part of the library only deals
> with
> archivers and "files" (which might only really be pointers to entries
> in Zip
> files, for example) by 'Class.
>
> The problem with the above is that:
>
> archiver.ads:18:13: operation can be dispatching in only one type
>
> Hopefully someone here knows a better way to handle this.

I don't know what PhysicsFS is, so I'm not clear on what you are
trying to accomplish.

Maybe your plan is to define concrete types derived from Archive_T and
File_T that go together, in pairs.  For example, a programmer might
define one package Archive_1 that defines Archive_1_T and File_1_T,
and another user might write a package Archive_2 that defines
Archive_2_T and File_2_T, but the intent is that the two would be
dependent---i.e. you would always use Open with two objects that go
together, such as an object of type Archive_1_T with a File_1_T, or an
Archive_2_T with a File_2_T, but never with an Archive_1_T and a
File_2_T.  In that case, you would make one parameter classwide, as
Dmitry suggested:

procedure Open
    (Archiver : Archiver_t'Class; -- Class-wide
     Path     : Virtual_t;
     File     : in out File_t) is abstract;

Then an implementation would need to check manually to make sure the
type is correct:

procedure Open
     (Archive : Archiver_T'Class;
      Path    : Virtual_T;
      File    : in out File_1_T) is
begin
   if Archive not in Archive_1_T then
      raise <some exception> with "Open on File_1_T used with wrong
archiver class";
   end if;
   declare
      The_Arch : Archive_1_T renames Archive_1_T(Archive);
   begin
      ...
      ... and now you have an Archive_1_T and a File_1_T to work with.

(I haven't checked this to make sure it's correct.  But it would be
something like this.)

By the way, for a while I was considering requesting a language change
to allow this sort of restricted multiple dispatch, in cases where a
primitive operation of two types could be declared and inherited for
two derived types that are derived in the same package, and when
dispatching, the program would check to make sure the two actual types
really were declared in the same package.  This would avoid having to
deal with M x N combinations of types---something that I think is an
issue with MI---since it only deals with pairs (or triplets, etc.) of
types that are defined to "go together".  I could try to write a
proposal if there's enough interest, but I think it's too late to get
into the next language revision.

If your plan is that Archiver and File types be more independent,
though, what you may need to do is to pick one of the parameters to
Open, say Archive (as above) to be a class-wide type, and then provide
enough operations on Archiver_T so that an implementation of Open
could dispatch on Archive to do whatever needs to be done with the
archive.

If you have some other idea about the relationship between Archiver
and File, then you might need to give me more specifics about how you
intend your package to be used.

                                 -- Adam