Cairo Ada binding questions

[Damien Carbonne <damien.carbonne@free.fr>]

I have started to write an Ada binding for Cairo
(http://cairographics.org). Cairo is written in C and I know how to
write a C/Ada thin binding.

My trouble is with a thick Ada API. I will try to explain it with an
example.
Cairo has a concept of Surface class that can is specialized into PDF 
Surface, SVG surface, etc. In the C API, Surfaces (as all Cairo 
"classes") are always manipulated through pointers. As a Surface can be 
shared, the C API provides a way to increment / decrement the reference 
counter.
So, I see here two concepts : Surface and Surface Handle.

In Ada, I could have something like this :
    type Surface_Record (<>) is tagged limited private;
    type Surface_Ref is access all Surface_Record'Class;
The would be used that way:
    procedure Foo (Surface : in [out] Surface_Record'Class; ...);
And when necessary:
   procedure Bar (Surface : in Surface_Ref; ...);
or, probably better(?):
   procedure Bar (Surface : access Surface_Record['Class]; ...);

However, by doing that, I let the user manage himself reference
counting. If I want to provide a Handle for ref counting, I have several
solutions based on smart pointers:
1) provide a Handle for root class of each hierarchy.
2) provide a Handle for each class of the hierarchy.
This second solution seems quite heavy to write. One needs to maintain
two parallel hierarchies, which is not really satisfying.
In both cases, smart pointers usage may also be quite uneasy, as there
is no way to make an object look like an access in Ada. At least, this
was impossible in Ada 95 (cf. Smart Pointers article by Matthew Heaney
on AdaPower).
So we would have something like this:
    type Surface_Handle is private;
    function Ref (Handle : Surface_Handle) return Surface_Ref;
that could be used like this :
    Surface : Surface_Handle;
begin
    Foo (Ref (Surface).all, ...);
or with the renaming trick to avoid this wordy thing.

There is also another solution, that would consist in hiding the Surface
concept, providing only the Surface_Handle one.
In that case, API would be modified like this :
    procedure Foo (Surface : in Surface_Handle'Class; ...);
Direction would (almost ?) always be in.

 From user point of view, this is far easier. From engineering point of
view, I really wonder.

Searching a solution to this issue, I looked at Ada.Text_IO and saw that
File_Type is often passed as a in parameter when, IMO, it should not.
For example :
    procedure New_Line (File : File_Type; Spacing : Positive_Count := 1);
Adding a new line modifies a file. This implies that File_Type must be
implemented with an indirection. Unless there is something I have not
understood, I don't find this really satisfying.

I Think my problem is quite general and may also exist in pure Ada code.
IIRC, GtkAda adopted the very first solution: It's user responsibility
to handle memory correctly.

To summarize solutions :
1) manual memory management
   1.a) Class Hierarchy and Ref (Ada Access) concepts
   1.b) ???
2) automatic memory management
   2.a) Class Hierarchy and Handle (Root only)
   2.b) Class Hierarchy and Handle hierarchy
   2.c) Handle hierarchy
   2.d) ???

Any advice would be appreciated !

Thanks.

Damien

PS1: If a Cairo Ada binding already exists, let me know !
PS2: If this binding reaches a satisfying state and is of interest to 
anyone, I will publish it.