1. مقدمه

ماهو المكون (الكائن) البرمجي؟

جامباس المكونات هي مكتوبة في مكتبات المشتركة C أو C++ التي تضيف وظائف جديدة لمترجم جامباس .

انهم يتصرفون مثل السائقين نحو kernel:

• The components and the interpreter communicate through the جامباس Programming Interface.

• They must be compiled inside the جامباس source package.

• They are executed in the interpreter environment, and so must not do whatever they want.

A المكوٍّن can contain:

• /wiki/lang/new2 classes that are added to the other جامباس classes. These classes are declared to the interpreter using a C structure that contains the description of each symbol, الطريقة (Method), constant and .

• Interpreter Hooks: special functions that implement important interpreter operations, like managing the event loop, reading the program parameters...

• A programming interface that enhances the جامباس Programming Interface, and that other components can use.

A component must have a name. This name is the the word gb followed by a dot-separated list of words describing the role of the component and another component it relies on, if any.

For example, gb.qt.kde is a component that transforms a جامباس application into a KDE application. This component relies on the gb.qt component, i.e. loading the first implies loading the second.

The جامباس Programming Interface

The جامباس Programming Interface is a set of utilities, functions and macros that allows you to:

• Describe the المكوٍّن.

• Define interpreter hooks.

• Manipulate arrays, hash tables...

• Manipulate جامباس native datatypes.

• Create جامباس arrays and collections.

• Raise events.

• Manipulate جامباس objects.

• Load a file from the project archive.

• Load other components.

• ...

The use of this programming interface is highly recommended, as it prevents a component from doing weird things.

The جامباس Programming Interface is a C structure that contains one function pointer for each function of the interface.

This structure is declared in the main file of your component and is automatically initialized by the interpreter at component loading.

Writing Good Components

Writing good components is the difficult part! Let's suppose you want to write a SDL المكوٍّن, i.e. a component that lets a جامباس project use all the power of the SDL library: graphics, sound, CD-ROM...

You can be content with just wrapping the library functions, structure and constants. It is the easy way, even if wrapping C structures and functions may not be possible in every case with جامباس.

Your component will be useful, but not very interesting for the جامباس programmer, because he will be obliged to program in C or C++ style.

Instead, you should rack your brain to create a different interface between جامباس and the library, by trying to generalize and simplify the original interface of the library.

That is what I did with QT: it is far easier to use the QT component than programming the QT library directly. And if one day somebody writes a GTK+ component, he will be able to use the same interface because I tried to generalize the QT interface by avoiding all the QT specific stuff... Well, to be honest, I put all the useful QT specific stuff into a dedicated extended component, gb.qt.ext

Component Source Organization

The source files of a المكوٍّن are stored in a sub-directory of the lib directory of the source package. The path of this directory reflects the name of the component.

For example, the gb.qt.kde component sources are stored in the .src/lib/qt/kde directory.

A typical component directory contains :

• The autoconf/automake stuff, i.e. a Makefile.am file that describes how to compile the component. (new topic)

• One source file and one header file for each main class implemented in the component.

• One main file that implements the entry points of the component.

• One component description file.

For example, here is the result of ls ./src/lib/qt/kde just before the compilation :

The component source directory structure looks something like this: