Las unidades le permiten agrupar cosas comunes (cualquier cosa que se pueda declarar), para que las usen otras unidades y programas. Son equivalentes a m\u00f3dulos y paquetes en otros idiomas. Tienen una secci\u00f3n de interfaz, donde declara lo que est\u00e1 disponible para otras unidades y programas, y luego la implementaci\u00f3n. Guarde la unidad MyUnit como myunit.pas (en min\u00fasculas con la extensi\u00f3n .pas).<\/p>\n\n\n\n
$mode objfpc}{$H+}{$J-}\nunit MyUnit;\ninterface\n\nprocedure MyProcedure(const A: Integer);\nfunction MyFunction(const S: string): string;\n\nimplementation\n\nprocedure MyProcedure(const A: Integer);\nbegin\n WriteLn('A + 10 is: ', A + 10);\nend;\n\nfunction MyFunction(const S: string): string;\nbegin\n Result := S + 'strings are automatically managed';\nend;\n\nend.<\/pre><\/div>\n\n\n\nLos programas finales se guardan como archivos myprogram.lpr (lpr = archivo de programa Lazarus; en Delphi usar\u00eda .dpr). Tenga en cuenta que aqu\u00ed son posibles otras convenciones, p. algunos proyectos solo usan .pas para el archivo de programa principal, algunos usan .pp para unidades o programas. Aconsejo usar .pas para unidades y .lpr para programas FPC\/Lazarus. <\/p>\n\n\n\n
Un programa puede utilizar una unidad mediante una palabra clave uses:<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\n\nprogram MyProgram;\n\nuses\n MyUnit;\n\nbegin\n WriteLn(MyFunction('Note: '));\n MyProcedure(5);\nend.\n<\/pre><\/div>\n\n\n\nUna unidad tambi\u00e9n puede contener secciones de inicializaci\u00f3n y finalizaci\u00f3n. Este es el c\u00f3digo que se ejecuta cuando el programa comienza y finaliza.<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit initialization_finalization;\ninterface\n\nimplementation\n\ninitialization\n WriteLn('Hello world!');\nfinalization\n WriteLn('Goodbye world!');\nend.<\/pre><\/div>\n\n\n\nUnidades que se llaman unas a otras<\/h3>\n\n\n\n Una unidad tambi\u00e9n puede usar otra unidad. Se puede usar otra unidad en la secci\u00f3n de interfaz, o solo en la secci\u00f3n de implementaci\u00f3n. El primero permite definir cosas p\u00fablicas nuevas (procedimientos, tipos\u2026) adem\u00e1s de las cosas de otra unidad. Este \u00faltimo es m\u00e1s limitado (si usa una unidad solo en la secci\u00f3n de implementaci\u00f3n, puede usar sus identificadores solo en su implementaci\u00f3n).<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit AnotherUnit;\ninterface\n\nuses\n Classes;\n\n{ The \"TComponent\" type (class) is defined in the Classes unit.\n That's why we had to use the Classes unit above. }\nprocedure DoSomethingWithComponent(var C: TComponent);\n\nimplementation\n\nuses SysUtils;\n\nprocedure DoSomethingWithComponent(var C: TComponent);\nbegin\n { The FreeAndNil procedure is defined in the SysUtils unit.\n Since we only refer to its name in the implementation,\n it was OK to use the SysUtils unit in the \"implementation\" section. }\n FreeAndNil(C);\nend;\n\nend.<\/pre><\/div>\n\n\n\nNo est\u00e1 permitido tener dependencias de unidades circulares en la interfaz. Es decir, dos unidades no pueden usarse entre s\u00ed en la secci\u00f3n de interfaz. La raz\u00f3n es que para \u00abcomprender\u00bb la secci\u00f3n de interfaz de una unidad, el compilador primero debe \u00abcomprender\u00bb todas las unidades que utiliza en la secci\u00f3n de interfaz. El lenguaje Pascal sigue estrictamente esta regla y permite una compilaci\u00f3n r\u00e1pida y una detecci\u00f3n completamente autom\u00e1tica en el lado del compilador de las unidades que se deben volver a compilar. No hay necesidad de usar complicados archivos Makefile para una tarea simple de compilaci\u00f3n en Pascal, y no hay necesidad de volver a compilar todo solo para asegurarse de que todas las dependencias se actualicen correctamente.<\/p>\n\n\n\n
Est\u00e1 bien hacer una dependencia circular entre unidades cuando al menos un \u00abuso\u00bb est\u00e1 solo en la implementaci\u00f3n. Por lo tanto, est\u00e1 bien que la unidad A use la unidad B en la interfaz y luego la unidad B use la unidad A en la implementaci\u00f3n.<\/p>\n\n\n\n
Calificando identificadores con nombre de unidad<\/h3>\n\n\n\n Diferentes unidades pueden definir el mismo identificador. Para mantener el c\u00f3digo f\u00e1cil de leer y buscar, por lo general debe evitarlo, pero no siempre es posible. En tales casos, la \u00faltima unidad en la cl\u00e1usula de usos \u00abgana\u00bb, lo que significa que los identificadores que introduce ocultan los mismos identificadores introducidos por unidades anteriores.<\/p>\n\n\n\n
Siempre puede definir expl\u00edcitamente una unidad de un identificador dado, us\u00e1ndolo como MyUnit.MyIdentifier. Esta es la soluci\u00f3n habitual cuando el identificador que desea utilizar desde MyUnit est\u00e1 oculto por otra unidad. Por supuesto, tambi\u00e9n puede reorganizar el orden de las unidades en su cl\u00e1usula de usos, aunque esto puede afectar otras declaraciones adem\u00e1s de la que est\u00e1 tratando de arreglar.<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nprogram showcolor;\n\n\/\/ Both Graphics and GoogleMapsEngine units define TColor type.\nuses Graphics, GoogleMapsEngine;\n\nvar\n { This doesn't work like we want, as TColor ends up\n being defined by GoogleMapsEngine. }\n \/\/ Color: TColor;\n { This works Ok. }\n Color: Graphics.TColor;\nbegin\n Color := clYellow;\n WriteLn(Red(Color), ' ', Green(Color), ' ', Blue(Color));\nend.<\/pre><\/div>\n\n\n\nEn el caso de las unidades, recuerda que tienen dos cl\u00e1usulas de uso: una en la interfaz y otra en la implementaci\u00f3n. La regla de que las unidades posteriores ocultan las cosas de las unidades anteriores se aplica aqu\u00ed de forma coherente, lo que significa que las unidades utilizadas en la secci\u00f3n de implementaci\u00f3n pueden ocultar los identificadores de las unidades utilizadas en la secci\u00f3n de interfaz. Sin embargo, recuerde que al leer la secci\u00f3n de la interfaz, solo importan las unidades utilizadas en la interfaz. Esto puede crear una situaci\u00f3n confusa, donde el compilador considera diferentes dos declaraciones aparentemente iguales:<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit UnitUsingColors;\n\n\/\/ INCORRECT example\n\ninterface\n\nuses Graphics;\n\nprocedure ShowColor(const Color: TColor);\n\nimplementation\n\nuses GoogleMapsEngine;\n\nprocedure ShowColor(const Color: TColor);\nbegin\n \/\/ WriteLn(ColorToString(Color));\nend;\n\nend.<\/pre><\/div>\n\n\n\nLa unidad Graphics (de Lazarus LCL) define el tipo de TColor. Pero el compilador no podr\u00e1 compilar la unidad anterior, alegando que no implement\u00f3 un procedimiento ShowColor que coincida con la declaraci\u00f3n de la interfaz. El problema es que la unidad GoogleMapsEngine tambi\u00e9n define un tipo TColor. Y se usa solo en la secci\u00f3n de implementaci\u00f3n, por lo tanto, sombrea la definici\u00f3n de TColor solo en la implementaci\u00f3n. La versi\u00f3n equivalente de la unidad anterior, donde el error es obvio, se ve as\u00ed:<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit UnitUsingColors;\n\n\/\/ INCORRECT example.\n\/\/ This is what the compiler \"sees\" when trying to compile previous example\n\ninterface\n\nuses Graphics;\n\nprocedure ShowColor(const Color: Graphics.TColor);\n\nimplementation\n\nuses GoogleMapsEngine;\n\nprocedure ShowColor(const Color: GoogleMapsEngine.TColor);\nbegin\n \/\/ WriteLn(ColorToString(Color));\nend;\n\nend.<\/pre><\/div>\n\n\n\nLa soluci\u00f3n es trivial en este caso, simplemente cambie la implementaci\u00f3n para usar expl\u00edcitamente TColor desde la unidad de gr\u00e1ficos. Tambi\u00e9n podr\u00eda solucionarlo moviendo el uso de GoogleMapsEngine, a la secci\u00f3n de interfaz y antes que Gr\u00e1ficos, aunque esto podr\u00eda tener otras consecuencias en casos reales, cuando UnitUsingColors definir\u00eda m\u00e1s cosas.<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit UnitUsingColors;\n\ninterface\n\nuses Graphics;\n\nprocedure ShowColor(const Color: TColor);\n\nimplementation\n\nuses GoogleMapsEngine;\n\nprocedure ShowColor(const Color: Graphics.TColor);\nbegin\n \/\/ WriteLn(ColorToString(Color));\nend;\n\nend.<\/pre><\/div>\n\n\n\nExponer los identificadores de una unidad de otra<\/h3>\n\n\n\n A veces desea tomar un identificador de una unidad y exponerlo en una nueva unidad. El resultado final deber\u00eda ser que el uso de la nueva unidad har\u00e1 que el identificador est\u00e9 disponible en el espacio de nombres.<\/p>\n\n\n\n
A veces, esto es necesario para preservar la compatibilidad con versiones anteriores de la unidad. A veces es bueno \u00abocultar\u00bb una unidad interna de esta manera.<\/p>\n\n\n\n
Esto se puede hacer redefiniendo el identificador en su nueva unidad.<\/p>\n\n\n\n
{$mode objfpc}{$H+}{$J-}\nunit MyUnit;\n\ninterface\n\nuses Graphics;\n\ntype\n { Expose TColor from Graphics unit as TMyColor. }\n TMyColor = TColor;\n\n { Alternatively, expose it under the same name.\n Qualify with unit name in this case, otherwise\n we would refer to ourselves with \"TColor = TColor\" definition. }\n TColor = Graphics.TColor;\n\nconst\n { This works with constants too. }\n clYellow = Graphics.clYellow;\n clBlue = Graphics.clBlue;\n\nimplementation\n\nend.<\/pre><\/div>\n\n\n\nTenga en cuenta que este truco no se puede hacer tan f\u00e1cilmente con procedimientos, funciones y variables globales. Con procedimientos y funciones, podr\u00eda exponer un puntero constante a un procedimiento en otra unidad (consulte Devoluciones de llamada (tambi\u00e9n conocidas como eventos, tambi\u00e9n conocidas como punteros a funciones, tambi\u00e9n conocidas como variables de procedimiento)), pero eso parece bastante sucio.<\/p>\n\n\n\n
La soluci\u00f3n habitual es entonces crear funciones triviales de \u00abenvoltura\u00bb que debajo simplemente llaman a las funciones desde la unidad interna, pasando los par\u00e1metros y devolviendo valores.<\/p>\n\n\n\n
Para que esto funcione con variables globales, se pueden usar propiedades globales (a nivel de unidad), consulte Propiedades<\/p>\n\n\n\n