Amiga Developer Site by i n n o i d e a | MorphOS | Amiga Developers | Compilers | Documents | Dev-HardFile v1.11 for UAE / real Amiga - readme - shot) | Unique/All Visitors: 77257/570053
Search manual for function in the   
AmigaE/MODULE

 interfacing to the amiga system with the v39 modules
-------------------------------------------------------
To use any other library than the five in the previous section, you'll
need to resort to modules. Also, if you wish to use some OBJECT or CONST
definition from the Amiga includes as is usual in C or assembler,
you'll need modules. Mod()ules are binary files which may include constant,
object, library and function (code) definitions. The fact that they're
binary has the advantage over ascii (as in C and assembly), that they
need not be compiled over and over again, each time your program is
compiled. The disadvantage is that they cannot simply be viewed; they
need a utility like ShowMod()ule to make their contents visible. The modules
that contain the library definitions (i.e the calls) are in the root of
emodules: (the modules dir in the distribution), the constant/object
definitions are in the subdirectories, structured just like the originals
from Commodore.
------------------------------------------------------------------------------

syntax:		MODULE ,...

Loads a module. A module is a binary file containing information on libraries,
constants, and sometimes functions. Using modules enables you to use
libraries and functions previously unknown to the compiler.

Now for an example, below is a short version of the source/examples/asldemo.e
source that uses modules to put up a filerequester from the 2.0 Asl.library.


MODULE 'Asl', 'libraries/Asl'

PROC main()
  DEF req:PTR TO filerequester
  IF aslbase:=OpenLibrary('asl.library',37)
    IF req:=AllocFileRequest()
      IF RequestFile(req) THEN WriteF()('File: "\s" in
"\s"\n',req.file,req.drawer)
      FreeFileRequest(req)
    ENDIF
    CloseLibrary(aslbase)
  ENDIF
ENDPROC


From the modules 'asl', the compiler takes asl-function definitions like
RequestFile(), and the global variable 'aslbase', which only needs to
be initialised by the programmer. From 'libraries/Asl', it takes
the definition of the filerequester object, which we use to read the
file the user picked. Well, that wasn't all that hard: did you think
it was that easy to program a filerequester in E?


 compiling own modules
-----------------------
with v3, you can gather all PROCs, CONSTs, OBJECTs and to
some extent also global variables that you feel somehow belong
together in one source, write "OPT MODULE" to signal EC that
this is supposed to be a module, and then compile all to a
.m file to be used in the main program, just like you used to
do with the old modules.

by default, all elements in a module are PRIVATE, i.e. not accessable
to the code that imports the .m file. to show which elememts
you wish to be visible in the module, simply write EXPORT
before it:

EXPORT ENUM TESTING,ONE,TWO,THREE,FOUR

EXPORT DEF important_glob_var, bla:PTR TO x

EXPORT OBJECT x
  next, index, term
ENDOBJECT

EXPORT PROC burp()
  /* whatever */
ENDPROC

"EXPORT" is useful in making a distinction between private and
public, especially when all functions of an OBJECT can be accessed
via PROCs, you may wish to keep OBJECT private as an effective
method of data hiding.
[EXPORT can be written on any line, doesn't affect everything though.]

If in a module _all_ elememts need to be exported (for example
one with only constants), a 'OPT EXPORT' will export all, without
the need for individual EXPORT keywords.

global variables require extra attention:
- try to avoid lots of global variables. having lot of globals
  in modules makes projects messy and error-prone
- globs in a module cannot have initialisations directly
  in the DEF statement (reason for this will become clear
  below). for example:
  DEF a             not     DEF a=1
  DEF a:PTR TO x    not     DEF a[10]:ARRAY OF x
- globals in a module which are not exported function as
  local for the module, i.e. they'll never clash with globals
  in other modules. those who _are_ exported though, are
  combined with the others, i.e. if in both the main program
  and in a module a variable with the same name are used,
  this will be one and the same variable. that's why
  one can write DEF a[10]:ARRAY OF x in the main program,
  and EXPORT DEF a:PTR TO x in the module, to share the
  array. Also, if both use for example 'gadtools.m',
  only one of the two needs to initialise 'gadtoolsbase'
  for both to be able to make calls to the library.
  If you do not want librarybases to be shared (i.e. you
  want to have a local, private library base), simply
  redeclare it in a DEF in the module that is not EXPORTed.
  If you export a variable in a general purpose
  module, make sure to give it a pretty unique name.
- using globals in modules which provide general purpose
  datatypes needs special attention, as the module may be
  in use from more than one other module, in which case
  it may be unclear who is responsable for resources.
  take good care of this.

Using modules in modules

This requires little extra attention. If the module (B) you include
in your own module (A) is one that only declares CONSTs, LIBRARYs and
OBJECTs (without code) nothing special happens, however if B includes
PROCs, then it's obvious this code needs to be linked later to the
main program when A is linked. Therefore if a main program uses A,
B will need to be present for compilation. The fact that A needs
B is stored in A, and can be viewed with ShowMod()ule. This chain
of uses may grow out to a tree of dependencies, which has the result
that if you use just one module in your program, a lot of others
are automatically linked to it. Thus, E's module system automatically
keeps track of dependancies that other languages need makefiles for.
EC also allows for circular inclusions, and loads/links modules at most
once (i.e. doesn't link unused modules). One thing E's module system
doesn't automatically do for you is recompile dependant modules. If
you change B, it is often necessary to recompile A too, since it
might be referring to offsets etc. in the old version of B, which
might cause code to crash. If this gets too complex in your project,
use a utility such as E-Build.


Try out the new ShowMod()ule  to see what EC puts in modules.


Including modules from other directories.

By default, a module name is prefixed by 'emodules:' to obtain
the actual file. Now you can prefix the name with a '*' to
denote the directory the source is in, so:

MODULE 'bla', '*bla'

if this statement would be in source 'WORK:E/burp.e', these two
modules would be 'emodules:bla.m' and 'WORK:E/bla.m'.

This is naturally the way to include components of your app into
other parts. If you write modules that you use in many of your programs
it would be handy to store them in the emodules hierarchy, and the
place for this is the 'emodules:other/' dir.



Logo by Emeric/SH
AmigaE/MODULE

No examples found...


Functions with "M":
MODULE
MapList()
Max()
MidStr()
Min()
Mod()
Mouse()
MouseX()
MouseY()
MsgCode()
MsgIaddr()
MsgQualifier()
Mul()

Last 15 uploaded Examples:

20071229151342 AmiSSL/X509_STORE_CTX_cleanup
20070708011052 GeekGadgets/getlogin
20060705053954 AmigaOS/OpenWorkbenchObjectA
20050801035639 SDL/SDL_Surface
20050727092732 BlitzBasic/LSL
20050718102843 SDL/SDL_WarpMouse
20050718072844 GeekGadgets/fread
20050714051528 SDL/SDL_ActiveEvent
20050714051514 SDL/SDL_ActiveEvent
20050701171401 GeekGadgets/errno
20050701171347 GeekGadgets/errno
20050627101951 SDL/SDL_FreeSurface
20050623152729 GeekGadgets/fork
20050619153102 GeekGadgets/tcdrain
20050615182849 AmigaOS/OpenScreen

Last 25 posts:

20050613235812 SDL/SDL_SetGammaRamp
20050526065000 AmiTCP/unistd.h
20050413041558 AmiSSL/X509_STORE_set_default_paths
20050409155750 AmigaDOS/Status
20050129230614 MUI/Calendar.mcc
20050128185620 GeekGadgets/hstrerror
20041126154558 BlitzBasic/LoadBank
20041123170704 GeekGadgets/gcvt
20041105222909 AmigaOS/CheckSignal
20040712190839 SDL/SDL_SetVideoMode
20040627090529 SDL/SDL_Init
20040519133228 GeekGadgets/fork
20040407124555 AmigaOS/AllocMem
20040403101120 GeekGadgets/inet_ntoa
20040327172814 GeekGadgets/random
20040327172714 GeekGadgets/srandom
20040313211937 BlitzBasic/ANALYZEDISK
20040303135237 GeekGadgets/mktemp
20040301131355 GeekGadgets/realpath
20040301123615 GeekGadgets/gcvt
20040301114000 GeekGadgets/htonl
20040301100209 GeekGadgets/realpath
20040229095437 GeekGadgets/time
20040211132618 GeekGadgets/getpid
20040209102818 AmigaOS/OpenWindow




Amiga.sf
AMIGIFT

Locations of visitors to this page

Page took 0.496056 seconds to load.