Module vs. package
With Mosel Release 2 it has become possible to define new user types directly in the Mosel language. An equivalent definition of the type 'task' within a package is the following.
public declarations task = public record name: string duration: real aflag: boolean duedate: integer end-record end-declarations
The access functions get... and set... may be defined to work exactly in the same way as those defined by our module. However, if we work with the dot notation to access the record fields the definition of these functions is not required. The type task defined by a package will use the standard conventions of Mosel for reading and writing records from/to a file—in a module these subroutines must be defined explicitly, which also implies that they are not confined to the standard Mosel format for reading and writing records.
A package cannot provide constructors for tasks, instead it might define subroutines to initialize (existing) tasks with data, for example, replacing the line
t(9):=task(3,false,9)
in our test model from Section Example by
create(t(9)) inittask(t(9), 3, false, 9)
or by using the Mosel constructor for records:
t(9):=task(.duration:=3,.aflag:=false,.duedate:=9)
Another feature that is not supported by packages is the definition of operators. The (default) comparison of two tasks defined through a package such as t(1)<>s compares whether we are looking at the same object (i.e., same address in memory)—the field-wise comparison of the contents of tasks needs to be implemented differently, for instance, by a subroutine issame(t(1), s).
To summarize the above, it is possible to implement all the functionality of the task module by the means of a package, requiring less programming effort where we rely on standard Mosel features (in particular for reading/writing types) at the expense of some flexibility. However, since same functionality does not mean same way of functioning the choice of the package or the module version of the type definition makes necessary certain modifications to the Mosel model that uses the respective library.
© 2001-2021 Fair Isaac Corporation. All rights reserved. This documentation is the property of Fair Isaac Corporation (“FICO”). Receipt or possession of this documentation does not convey rights to disclose, reproduce, make derivative works, use, or allow others to use it except solely for internal evaluation purposes to determine whether to purchase a license to the software described in this documentation, or as otherwise set forth in a written software license agreement between you and FICO (or a FICO affiliate). Use of this documentation and the software described in it must conform strictly to the foregoing permitted uses, and no other use is permitted.
