[m-dev.] Module qualification of typeclass methods

[Simon Taylor]

On 20-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> On Tue, Nov 20, 2001 at 08:08:09PM +1100, Fergus Henderson wrote:
> > On 30-Oct-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > 
> > > Would it be better to add an `import_package' declaration, which
> > > is like `import_module', but also imports all sub-modules of the
> > > imported modules.
> > 
> > I like this suggestion better than `:- automatic_import', because it
> > puts the control over what is imported in the importer rather than
> > the importee.
> >
> I am also happy with this suggestion.  The only difference between the
> two is that auto_import provides a mechanism to avoid doing to much
> importing.  However I don't see that as much of an advantage, as I can't
> see many situations where you don't want all the sub-modules anyway.

I can. In the .NET class library, the System.Data namespace defines
a bunch of common classes which are used by the larger sub-namespaces
for the different data source types.

The module layout is:

System.Data
	% Classes
	Constraint
	DataColumn
	DataRow
	DataTable
	etc.

	% Larger sub-modules
	System.Data.Common
	System.Data.OleDb
	System.Data.SqlClient
	System.Data.SqlTypes
	etc.

If the System.Data.{SqlClient,SqlTypes,OleDb,Common} modules are all used
then `:- import_package System.Data.*' might be appropriate, but I
shouldn't be tempted to import everything just to use some of the
basic classes (DataColumn, etc.) in System.Data. `:- auto_import'
should be used to import the modules for the basic classes.

Simon.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------