I would expect the user to explicitly import those method, I did not preclude their existence. And it would be quite reasonable to support the existing import all syntax hence
using MyModule ^ imports only those functions which explicitly reference user types defined in the module importall MyModule.Extensions ^imports the additional functionality on base types if I subsequently import another function which conflicts then we throw an error. This would mean that the vast majority of non conflicting functions can be trivially exported and used without a namespace qualifier and extensions to base types would also work, but with the name collision check in place. I don't believe this violates the expression problem ? On Wednesday, April 29, 2015 at 1:55:14 PM UTC-4, Stefan Karpinski wrote: > > > I made the point at the outset that it isn't hard (or expensive) if the > *exported >> *functions from a module *must reference types defined in that module*. >> Hence the suggestion that module developers should only be able to export >> functions which reference owned/hard/contained/user types. >> > > Unless I'm misunderstanding, this is a very limiting restriction. It would > mean, for example, that you can't define and export a generic > square(::Number) function. That's a silly example, but it's completely > standard for packages to export new functions that operate on pre-existing > types that don't dispatch on any type that "belongs" to the exporting > module. > > Another way of looking at this is that such a restriction would prevent > solving half of the expression problem > <http://en.wikipedia.org/wiki/Expression_problem>. In object-oriented > languages, extending existing operations to new types is easily done via > subtyping, but adding new operations to existing types is awkward or > impossible. In functional languages, adding new operations to existing > types is easy, but extending existing operations to new types is awkward or > impossible. Multiple dispatch lets you do both easily and intuitively – so > much so that people can easily forget why the expression problem was a > problem in the first place. Preventing the export of new functions > operating only on existing types would hobble the language, making it no > more expressive than traditional object-oriented languages. >
