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?
>>>
>>>
>>
>>
