>
>
> If Module A has connect(value::Any), and I add a module B with
> connect(value::TypeB), I don't see a problem with calls to connect with
> something of TypeB "changing" the behavior
> of Module A by not letting it grab *all* calls to connect().
> Maybe it's still too early in the morning, but I still don't see the
> problem here... you go to the most specific type, not the the generic one...
>
Example, assume there exists an entity relationship graph module that has a
"connect" function that connects a relationship between two named nodes and
attaches a piece of unknown data:
module relationship
connect(data::Any, from::UTF8string, to::UTF8string) = ...
end
And a database module where you connect to the named database with a
username, note this obeys the rule "must use type defined in same module":
module scotts_database_module
type scotts_database end
connect(db::scotts_database, name::UTF8string, user::UTF8string) = ...
end
In my user code *assuming functions merged* :
using relationships, scotts_database_module # function connect now has two
methods
#I make lots of relationship connections like
connect(1, "nodea", "nodeb") # connection with an integer data
connect("some text", "nodeb", "nodec") # connection with a string data
# now I want to connect two nodes with one of your excellent databases as
the data
sd = scotts_database()
connect(sd, "nodea", "nodeb") # connection with a database data
huh? why is my best customer getting a *runtime* error "no database named
'nodea'"?
[...]
> Maybe this is just in 0.4, but you can specify the type of a Varargs
> parameter, i.e. x::TypeB...
>
Yes, but there can still be any number of parameters of that type in a
call. f(x::TypeB...) has to be checked against f(a::TypeA, b::TypeB,
c::TypeC) because the relationship between TypeA and TypeB and between
TypeC and TypeB could be such that again merging these functions will
change the dispatch of f(x::TypeB...). Its not impossible to do it, but it
significantly complicates the checking algorithm.
[...]
> I mean if the method is a parametric method eg f{T}(a::T) the type of 'a'
>> depends on the parameter T. IIUC the method f{T} gets re-compiled for all
>> types that it gets as parameters, where there is no existing method, so,
>> without knowing all *uses* of f(), Julia can't know which methods exist to
>> merge.
>>
>
> In that case, the module writer would need to have something like f{T <:
> Union(TypeB, MyOtherBType)} in order for the compiler to use T.
>
Probably its too late (timezones!!), but I don't see what you mean?
>
> However, I'd said that I wouldn't depend on that, I'd want a keyword for
> function definition, that declares that this function is designed to be
> unambigous
> (the compiler should still do the checking though).
>
I am all for being explicit, but I'm not sure what you want the keyword
semantics to be?
> [...]
>
> If each module is using functions with different types, how can their
> behavior change?
>
Indeed, if *each* module is using types that do not overlap it cannot, what
I was saying was that you need to check that by looking at *both* modules,
not just locally at one module.
> [...]
>
> Again, I think with a keyword or syntax to show that the programmer means
> this to be a new generic function, that the programmer makes the guarantee
> that it is unambiguous,
> it is.
>
In the scotts_database example above, how could you, as the writer of that
module make such a guarantee, you have no way of knowing I would use your
module with the relationship module, in fact you didn't even know it
existed. Or "connect" could even just be a function in the users own code,
not even in a module.
>
>
>>
>>> 3) If it is meant to be only callable via module.name (or
>>> module.module.name [etc]), outside the module, i.e. it is not allowed
>>> to make it extend something at the higher level.
>>>
>>
>> "Only callable by qualified name" depends on the situation in the user
>> code, which modules they "using" into a specific scope. When a module is
>> being compiled this is not known, so it can't affect anything in the module.
>>
>
> No, I am saying that this is a new capability that Julia presently does
> not have (AFAIK). How do you say that the user code is not allowed to use
> "using" on this function?
>
Don't export it?
> [...]
> What I'm saying is that ONLY for functions where the module writer has
> specified that the method(s) are supposed to be unambigous, would it do any
> tests and try to merge.
>
Otherwise, it should act as it does now for exported functions, and simply
> not merge if the name conflicts.
>
Again I'm not sure how the module writer can know that?
> [...]
>> Agree, you can't extend a function from another module in a way thats
>> only visible in this module. Thats why extension needs to be explicit "I
>> do mean it, and I understand it has global consequences". But independent
>> objects that are not exported should already be isolated properly I believe.
>>
>>
> Unfortunately, they leak into the global method table :-(
>
Which "they" do you mean?
>
> Scott
>
