For a concrete example, the export of the `find` method in LibExpat.jl was
recently noted to conflict with the export of `Base.find`. Even though
there would have been no ambiguity to merging the definitions, the
consensus was that they should not be merged since the definition of the
function in base ("find the index of an element in a iterable") was
different from the definition for this name being used by libexpat ("find
the element(s) that match a search string").https://github.com/amitmurthy/LibExpat.jl/issues/30 On Fri, May 15, 2015 at 9:36 PM <ele...@gmail.com> wrote: > > > On Saturday, May 16, 2015 at 6:58:18 AM UTC+10, Scott Jones wrote: >> >> About functions that actually take the same types (which means they are >> operating on types they they didn't define themselves), I think the new >> approach in 0.4 (give a warning and don't merge in the "new" meaning) is >> correct. >> I would not like to see that change to have the ambiguity only resolved / >> warned about at run-time. >> >> I've said all along, I'm only talking about cases where there is no >> ambiguity... >> Package A defines TypeA, and all of it's exported functions always have >> TypeA in their method signature (even if it's only `::Type{TypeA})`. Say >> it has a "connect(db::TypeA, ipaddr, port)" method... >> Package B defines TypeB, (same as above), Why should it not be able to >> also define a "connect(db::TypeB,datasetname:UTF8String)"? >> > > Hi Scott, > > I'm not sure you meant it, but the way you wrote that makes it sound like > a simple fairly local test: > > if module defines *concrete* type and all methods have a parameter of that > type: merge ok > > But as I understand it, the test would need to be more complex, for > function 'f' something like: > > for each function named f in the current scope: > for each method of the function: > for each parameter position in the method: > if parameter is varargs: can't merge # not sure how else to > handle varargs, can fill infinite parameter positions > get the type of the parameter > if the type depends on a generic parameter: can't merge # since > the types the generic parameter takes depends on the uses, and we don't > know that until we know if it merges or not > if the type of the parameter is a subtype of a type already > used in this parameter position in a different function: can't merge # > "ambiguous" > add the type to the list for this parameter position > whew, ok to merge > > Since Julia is a dynamic JITed language not an AOT language I think this > can be run at any time the JIT compiles some new code. That could do > terrible things to performance. > > Cheers > Lex > > > > >> >> Scott >> >> >> On Friday, May 15, 2015 at 9:13:11 AM UTC-4, Michael Francis wrote: >>> >>> @Scott, @Toivo >>> >>> In my mind this changing the meaning of existing code is happening all >>> the time with the verbs in Base. Each time I use a module it can (and >>> likely does) inject new behavior for verbs defined in Base ( or for verbs >>> defined in any other module) These silently change the way other modules >>> work. This is actually the beauty of the type system as it allows a module >>> to add features to another module without having to fork the module. The >>> only thing you can't do is add new verbs to an existing module. >>> >>> Is that not the case ? >>> >>> >>> On Friday, May 15, 2015 at 8:08:51 PM UTC+10, Scott Jones wrote: >>>> >>>> >>>> >>>> On Thursday, May 14, 2015 at 3:13:09 PM UTC-4, Toivo Henningsson wrote: >>>>> >>>>> I don't think it should be allowed. What if two packages try to add >>>>> functions with the same name to Base that do completely different things? >>>>> And what if they are both applicable to some of the same argument types? >>>>> >>>> >>>> As long as there is no ambiguity in the types, why should they not be >>>> able to? >>>> That is *way* too restrictive... >>>> >>> >>> Because if some module adds an ambiguous type it will silently change >>> the meaning of existing code. >>> >>> >>>> >>>> >>>>> Beyond that, I think being able to add definitions to a module from >>>>> the outside comes with an extra set of problems. What if you define a >>>>> function that shadows a function that it was using from another module? >>>>> What if there was a big where someone was trying to access a function from >>>>> another module that wasn't there, but is was named because the function >>>>> had >>>>> been introduced from the outside? >>>> >>>> >>> >>>
