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