[m-dev.] Module qualification of typeclass methods
Fergus Henderson
fjh at cs.mu.OZ.AU
Fri Nov 23 03:59:43 AEDT 2001
On 23-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 22-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Wed, Nov 21, 2001 at 12:10:39AM +1100, Simon Taylor wrote:
> > > 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.
> > >
> > I would argue that this is a packaging problem. The .NET library
> > designers decided to put all these classes into one deployment unit
> > (assembly).
> >
> > I would argue that the namespace pollution issue is due to bad library
> > design, rather then a problem with the import_package declaration.
>
> I would argue that it's a bit of both.
>
> Any extension to the module system should gracefully handle libraries
> which aren't organised in the ideal way (whatever that is).
> As this example demonstrates, `:- import_package' does not.
I don't find this example particularly convincing...
just use `:- use_package'.
Anyway, even if this example was serious problem,
is `:- auto_import' going to solve it?
The user of the package is at the mercy of the package designer.
If the package designer didn't factor the modules well in the first place,
what makes you think they're going to use `:- auto_import' well?
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the developers
mailing list