Yes! Precisely what I’ve been advocating all along! Scott
> On Apr 29, 2015, at 2:06 PM, Michael Francis <[email protected]> wrote: > > 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.
