Lex, MA Laforge, It sounds like many of us agree, I'm not convinced by the it's hard argument though -
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. This was shot down as being too restrictive, personally for most modules I am likely to write / define this rule would be sufficient. Where a module exports functions which only only reference base types I'd argue that the user of the module should explicitly import those functions, not implicitly. For example if I wanted to define some new function which work on Arrays/Vectors I can certainly do so they should either be qualified in usage Transgressions.sort( [ 1,2,7 3 ] ) or explicitly imported import Transgressions: sort ^ the above should fail as it conflicts with sort in Base I fail to see why the burden of name spacing should be born by every user. I also fail to see why these simple rules are not Julian or are too restrictive, quite the opposite in fact. In the database example given previously there is significant negative value in having namespace qualification - it implies that if I wanted to implement a database driver to the same interface I either have to extend the methods in the other persons module ( seems like the wrong thing to do ) or define a parallel impl which can not be used at the same time in the same module without qualification of both, even though there is no ambiguity since all the methods reference a type that I have defined in the module. This just seems wrong. To me the import/using/module rules that exist currently break the promise of multiple dispatch and are at best confusing and at worse make programming in the large fragile and prone to breaks with every new export / method addition.. On Wednesday, April 29, 2015 at 9:27:47 AM UTC-4, MA Laforge wrote: > > Hi Lex, > > I think we agree here. I also got the same impression as you regarding > your statement "it might be possible for Julia to determine that there is > no overlap between the methods simply, it is my understanding that in > general it could be an expensive whole program computation". > > For me, I think this impression is derived from one of Jeff's posts: > > " > Comparing method signatures is computationally difficult (exponential > worst case!), while looking for a symbol in a list is trivial. Warnings for > name conflicts may be annoying, but at least it's dead obvious what's > happening. If a subtle adjustment to a signature affects visibility > elsewhere, I'd think that would be much harder to track down. > " > > ...But I am not absolutely certain I am following some of this discussion > correctly.... >
