[lazarus] Wrapping glib with objects

[Michael Van Canneyt]

On Mon, 14 Jun 1999, John Margaglione wrote:

> Hi all,
> 
> I'm looking at wrapping up the glib functions in object wrappers.  Let me explain why:
> 
> 1.  There is WAY too much useful functionality in there to pass up.  The FCL needs most of that functionality available, but programmers should not have to revert to C programming constructs to use it.
> 
> 2.  By wrapping up the functions in objects, we open up the possibility of converting the object implementations to pure pascal in the future, with minimal impact to application code (including our implementation of the gtk libraries).
> 
> Example:
> 
> class TLinkedList = class(TObject)
>   private
>     _list: TGList;
>   public
>     constructor Create;
>     destructor Destroy; override;
> 
>     procedure Insert( obj: TObject );
>     procedure Remove( obj: TObject );
>   end;
> 
> The public interface is now clear of glib constructs/variables, and the application programmer doesn't need to know/care about glib.
> 
> There are a few issues I would like some comments upon, though.
> 
> 1.  glib likes to pass around gpointers.  I like to pass around TObjects.  There are merits in doing both.
> By passing around TObjects we wave the application programmer from constantly doing this: pointer( thing ).
>  But, by restricting the user to TObjects, they can't store records.  The obvious solution is to overload
> the Inser function so that it accepts both pointers and TObjects.  Any other suggestions?

Why not make it a descendent of TList or TStrings (with whatever enhancements you want) ?
I was planning to do this, but due to lack of time I didn't do it yet.

>
> 2.  glib provides OS-independed threading/thread synchronization control.  How should this be wrapped?
> Should it be a class, TThread, like Delphi 3 does it?  Or should we integrate threading into TObject,
> like Java does it?  I love the Java constructs, but that is a LOT more work on our part!  Any suggestions?

TThread is implemented already. If possible, a descendent should be used.

Michael.