Provided by: libprima-perl_1.28-1.4_amd64 bug

NAME

       gencls - class interface compiler for Prima core modules

SYNOPSIS

         gencls --h --inc --tml -O -I<name> --depend --sayparent filename.cls

DESCRIPTION

       Creates headers with C macros and structures for Prima core module object definitions.

ARGUMENTS

       gencls accepts the following arguments:

       --h Generates .h file ( with declarations to be included in one or more files )

       --inc
           Generates .inc file ( with declarations to be included in only file )

       -O  Turns optimizing algorithm for .inc files on. Algorithm is based on an assumption,
           that some functions are declared identically, therefore the code piece that handles
           the parameter and result conversion can be shared. With "-O" flag on, a thunk body is
           replaced to a call to a function, which name is made up from all method parameters
           plus result.  Actual function is not written in .inc file, but in .tml file.  All
           duplicate declarations from a set of .tml files can be removed and the reminder
           written to one file by tmlink utility.

       --tml
           Generates .tml file. Turns "-O" automatically on.

       -Idirname
           Adds a directory to a search path, where the utility searches for .cls files. Can be
           specified several times.

       --depend
           Prints out dependencies for a given file.

       --sayparent
           Prints out the immediate parent of a class inside given file.

SYNTAX

       In short, the syntax of a .cls file can be described by the following scheme:

         [ zero or more type declarations ]
         [ zero or one class declaration ]

       Gencls produces .h, .inc or .tml files, with a base name of the .cls file, if no object or
       package name given, or with a name of the object or the package otherwise.

   Basic scalar data types
       Gencls has several built-in scalar data types, that it knows how to deal with. To 'deal'
       means that it can generate a code that transfers data of these types between C and perl,
       using XS ( see perlguts ) library interface.

       The types are:

          int
          Bool
          Handle
          double
          SV*
          HV*
          char *
          string ( C declaration is char[256] )

       There are also some derived built-in types, which are

          long
          short
          char
          Color
          U8

       that are mapped to int. The data undergo no conversion to int in transfer process, but it
       is stored instead to perl scalar using newSViv() function, which, in turn, may lose bits
       or a sign.

   Derived data types
       The syntax for a new data types definition is as follows:

          <scope> <prefix> <id> <definition>

       A scope can be one of two pragmas, "global" or "local".  They hint the usage of a new data
       type, whether the type will be used only for one or more objects. Usage of "local" is
       somewhat resembles C pragma static.  Currently the only difference is that a function
       using a complex local type in the parameter list or as the result is not a subject for
       "-O" optimization.

   Scalar types
       New scalar types may only be aliased to the existing ones, primarily for C coding
       convenience.  A scalar type can be defined in two ways:

       Direct aliasing
           Syntax:

             <scope> $id => <basic_scalar_type>;

           Example:

             global $Handle => int;

           The new type id will not be visible in C files, but the type will be substituted over
           all .cls files that include this definition.

       C macro
           Syntax:

             <scope> id1 id2

           Example:

             global API_HANDLE UV

           Such code creates a C macro definition in .h header file in form

             #define id1 id2

           C macros with parameters are not allowed. id1 and id2 are not required to be present
           in .cls name space, and no substitution during .cls file processing is made.  This
           pragma usage is very limited.

   Complex types
       Complex data types can be arrays, structs and hashes.  They can be a combination or a
       vector of scalar ( but not complex) data types.

       Gencls allows several combinations of complex data types that C language does not
       recognize. These will be described below.

       Complex data types do not get imported into perl code.  A perl programmer must conform to
       the data type used when passing parameters to a function.

       Arrays
           Syntax:

             <scope> @id <basic_scalar_type>[dimension];

           Example:

             global @FillPattern U8[8];

           Example of functions using arrays:

             Array * func( Array a1, Array * a2);

           Perl code:

             @ret = func( @array1, @array2);

           Note that array references are not used, and the number of items in all array
           parameters must be exactly as the dimensions of the arrays.

           Note: the following declaration will not compile with C compiler, as C cannot return
           arrays. However it is not treated as an error by gencls:

             Array func();

       Structs
           Syntax:

             <scope> @id {
                <basic_scalar_type> <id>;
                ...
                <basic_scalar_type> <id>;
             };

           Example:

             global @Struc {
                int    number;
                string id;
             }

           Example of functions using structs:

             Struc * func1( Struc a1, Struc * a2);
             Struc   func2( Struc a1, Struc * a2);

           Perl code:

             @ret = func1( @struc1, @struc2);
             @ret = func2( @struc1, @struc2);

           Note that array references are not used, and both number and order of items in all
           array parameters must be set exactly as dimensions and order of the structs. Struct
           field names are not used in perl code as well.

       Hashes
           Syntax:

             <scope> %id {
                <basic_scalar_type> <id>;
                ...
                <basic_scalar_type> <id>;
             };

           Example:

             global %Hash {
                int    number;
                string id;
             }

           Example of functions using hashes:

             Hash * func1( Hash a1, Hash * a2);
             Hash   func2( Hash a1, Hash * a2);

           Perl code:

             %ret = %{func1( \%hash1, \%hash2)};
             %ret = %{func2( \%hash1, \%hash2)};

           Note that only hash references are used and returned.  When a hash is passed from perl
           code it might have some or all fields unset. The C structure is filled and passed to a
           C function, and the fields that were unset are assigned to a corresponding
           C_TYPE_UNDEF value, where TYPE is one of NUMERIC, STRING and POINTER literals.

           Back conversion does not count on these values and always returns all hash keys with a
           corresponding pair.

   Namespace section
       Syntax:

          <namespace> <ID> {
             <declaration>
             ...
             <declaration>
          }

       A .cls file can have zero or one namespace sections, filled with function descriptions.
       Functions described here will be exported to the given ID during initialization code. A
       namespace can be either "object" or "package".

       The package namespace syntax allows only declaration of functions inside a "package"
       block.

           package <Package ID> {
               <function description>
               ...
           }

       The object namespace syntax includes variables and properties as well as functions (
       called methods in the object syntax ).  The general object namespace syntax is

           object <Class ID> [(Parent class ID)] {
              <variables>
              <methods>
              <properties>
           }

       Within an object namespace the inheritance syntax can be used:

           object <Class ID> ( <Parent class ID>)  { ... }

       or a bare root object description ( with no ancestor )

           object <Class ID> { ... }

       for the object class declaration.

   Functions
       Syntax:

           [<prefix>] <type> <function_name> (<parameter list>) [ => <alias>];

       Examples:

               int   package_func1( int a, int b = 1) => c_func_2;
               Point package_func2( Struc * x, ...);
        method void  object_func3( HV * profile);

       A prefix is used with object functions ( methods ) only.  More on the prefix in Methods
       section.

       A function can return nothing ( void ), a scalar ( int, string, etc ) or a complex (
       array, hash ) type. It can as well accept scalar and complex parameters, with type
       conversion that corresponds to the rules described above in "Basic scalar data types"
       section.

       If a function has parameters and/or result of a type that cannot be converted
       automatically between C and perl, it gets declared but not exposed to perl namespace.  The
       corresponding warning is issued.  It is not possible using gencls syntax to declare a
       function with custom parameters or result data.  For such a purpose the explicit C
       declaration of code along with "newXS" call must be made.

       Example: ellipsis (...) cannot be converted by gencls, however it is a legal C
       construction.

         Point package_func2( Struc * x, ...);

       The function syntax has several convenience additions:

       Default parameter values
           Example:

             void func( int a = 15);

           A function declared in such way can be called both with 0 or 1 parameters. If it is
           called with 0 parameters, an integer value of 15 will be automatically used.  The
           syntax allows default parameters for types int, pointer and string and their scalar
           aliases.

           Default parameters can be as many as possible, but they have to be in the end of the
           function parameter list.  Declaration "func( int a = 1, int b)" is incorrect.

       Aliasing
           In the generated C code, a C function has to be called after the parameters have been
           parsed. Gencls expects a conformant function to be present in C code, with fixed name
           and parameter list. However, if the task of such function is a wrapper to an identical
           function published under another name, aliasing can be preformed to save both code and
           speed.

           Example:

              package Package {
                 void func( int x) => internal;
              }

           A function declared in that way will not call Package_func() C function, but
           internal() function instead. The only request is that internal() function must have
           identical parameter and result declaration to a func().

       Inline hash
           A handy way to call a function with a hash as a parameter from perl was devised. If a
           function is declared with the last parameter or type "HV*", then parameter translation
           from perl to C is performed as if all the parameters passed were a hash. This hash is
           passed to a C function and it's content returned then back to perl as a hash again.
           The hash content can be modified inside the C function.

           This declaration is used heavily in constructors, which perl code is typical

              sub init
              {
                 my %ret = shift-> SUPER::init( @_);
                 ...
                 return %ret;
              }

           and C code is usually

              void Obj_init ( HV * profile) {
                  inherited init( profile);
                  ... [ modify profile content ] ...
              }

   Methods
       Methods are functions called in a context of an object.  Virtually all methods need to
       have an access to an object they are dealing with. Prima objects are visible in C as
       Handle data type. Such Handle is actually a pointer to an object instance, which in turn
       contains a pointer to the object virtual methods table ( VMT ).  To facilitate an OO-like
       syntax, this Handle parameter is almost never mentioned in all methods of an object
       description in a cls file, although being implicit counted, so every cls method
       declaration

          method void a( int x)

       for an object class Object is reflected in C as

          void Object_a( Handle self, int x)

       function declaration. Contrary to package functions, that gencls is unable to publish if
       it is unable to deal with the unsupported on unconvertible parameters, there is a way to
       issue such a declaration with a method. The primary use for that is the method name gets
       reserved in the object's VMT.

       Methods are accessible in C code by the direct name dereferencing of a "Handle self" as a
       corresponding structure:

           ((( PSampleObject) self)-> self)-> sample_method( self, ...);

       A method can have one of six prefixes that govern C code generation:

       method
           This is the first and the most basic method type.  It's prefix name, "method" is
           therefore was chosen as the most descriptive name. Methods are expected to be coded in
           C, the object handle is implicit and is not included into a .cls description.

              method void a()

           results in

              void Object_a( Handle self)

           C declaration. A published method automatically converts its parameters and a result
           between C and perl.

       public
           When the methods that have parameters and/or result that cannot be automatically
           converted between C and perl need to be declared, or the function declaration does not
           fit into C syntax, a "public" prefix is used. The methods declared with "public" is
           expected to communicate with perl by means of XS ( see perlxs ) interface. It is also
           expected that a "public" method creates both REDEFINED and FROMPERL functions ( see
           Prima::internals  for details). Examples are many throughout Prima source, and will
           not be shown here. "public" methods usually have void result and no parameters, but
           that does not matter much, since gencls produces no conversion for such methods.

       import
           For the methods that are unreasonable to code in C but in perl instead, gencls can be
           told to produce the corresponding wrappers using "import" prefix. This kind of a
           method can be seen as "method" inside-out. "import" function does not need a C
           counterpart, except the auto-generated code.

       static
           If a method has to be able to work both with and without an object instance, it needs
           to be prepended with "static" prefix.  "static" methods are all alike "method" ones,
           except that "Handle self" first parameter is not implicitly declared.  If a "static"
           method is called without an object ( but with a class ), like

              Class::Object-> static_method();

           its first parameter is not a object but a "Class::Object" string.  If a method never
           deals with an object, it is enough to use its declaration as

              static a( char * className = "");

           but is if does, a

              static a( SV * class_or_object = nil);

           declaration is needed. In latter case C code itself has to determine what exactly has
           been passed, if ever. Note the default parameter here: a "static" method is usually
           legible to call as

             Class::Object::static_method();

           where no parameters are passed to it. Without the default parameter such a call
           generates an 'insufficient parameters passed' runtime error.

       weird
           We couldn't find a better name for it. "weird" prefix denotes a method that combined
           properties both from "static" and "public". In other words, gencls generates no
           conversion code and expects no "Handle self" as a first parameter for such a method.
           As an example Prima::Image::load can be depicted, which can be called using a wide
           spectrum of calling semantics ( see Prima::image-load for details).

       c_only
           As its name states, "c_only" is a method that is present on a VMT but is not
           accessible from perl. It can be overloaded from C only. Moreover, it is allowed to
           register a perl function with a name of a "c_only" method, and still these entities
           will be wholly independent from each other - the overloading will not take place.

           NB: methods that have result and/or parameters data types that can not be converted
           automatically, change their prefix to "c_only".  Probably this is the wrong behavior,
           and such condition have to signal an error.

   Properties
       Prima toolkit introduces an entity named property, that is expected to replace method
       pairs whose function is to acquire and assign some internal object variable, for example,
       an object name, color etc. Instead of having pair of methods like Object::set_color and
       Object::get_color, a property Object::color is devised. A property is a method with the
       special considerations, in particular, when it is called without parameters, a 'get' mode
       is implied. In contrary, if it is called with one parameter, a 'set' mode is triggered.
       Note that on both 'set' and 'get' invocations "Handle self" first implicit parameter is
       always present.

       Properties can operate with different, but fixed amount of parameters, and perform a 'set'
       and 'get' functions only for one. By default the only parameter is the implicit "Handle
       self":

          property char * name

       has C counterpart

          char * Object_name( Handle self, Bool set, char * name)

       Depending on a mode, "Bool set" is either "true" or "false".  In 'set' mode a C code
       result is discarded, in 'get' mode the parameter value is undefined.

       The syntax for multi-parameter property is

          property long pixel( int x, int y);

       and C code

          long Object_pixel( Handle self, Bool set, int x, int y, long pixel)

       Note that in the multi-parameter case the parameters declared after property name are
       always initialized, in both 'set' and 'get' modes.

   Instance variables
       Every object is characterized by its unique internal state.  Gencls syntax allows a
       variable declaration, for variables that are allocated for every object instance. Although
       data type validation is not performed for variables, and their declarations just get
       copied 'as is', complex C declarations involving array, struct and function pointers are
       not recognized.  As a workaround, pointers to typedef'd entities are used.  Example:

          object SampleObject {
             int x;
             List list;
             struct { int x } s; # illegal declaration
          }

       Variables are accessible in C code by direct name dereferencing of a "Handle self" as a
       corresponding structure:

           (( PSampleObject) self)-> x;

AUTHORS

       Dmitry Karasik, <dmitry@karasik.eu.org>.  Anton Berezin, <tobez@tobez.org>.

SEE ALSO

       Prima::internals, tmlink

COPYRIGHT

       This program is distributed under the BSD License.