Sorry, I mean import testmod.bar .
On Sunday, July 27, 2014 12:32:52 AM UTC+1, Cristóvão Duarte Sousa wrote:
>
> Doing import.bar in the user dfined code side seems to solve the problem.
> I expected that exporting bar out of the module would also solve the
> problem, however, it doesn't.
>
> On Saturday, July 26, 2014 10:01:50 PM UTC+1, Abe Schneider wrote:
>>
>> I have a pattern that has come up multiple times where in a module I
>> might have some function `foo` which will call some other function `bar` on
>> a given type. The exact function `bar` isn't defined yet because it is
>> defined by the user-type. The problem I run into is that if `bar` is
>> defined outside of the module, `foo` won't see it.
>>
>> Here is a simple example:
>> module testmod
>>
>> export foo, Baz
>>
>> abstract Baz
>>
>> bar(x::Baz) = nothing
>>
>> function foo(x::Baz)
>> return bar(x)
>> end
>>
>> end
>>
>> with the user-defined code:
>> using testmod
>>
>> type ConcreteBaz <: Baz
>> value::Int64
>> end
>>
>> function bar(baz::ConcreteBaz)
>> return baz.value
>> end
>>
>> baz = ConcreteBaz(42)
>> println("result = $(foo(baz))")
>>
>> The output is `result = nothing`, and thus the wrong function is called.
>> If I move all of the code to the same file it works.
>>
>> My question is: is this expected behavior? If so, what's the proper way
>> of creating an interface for an abstract type which can later be overridden
>> in a user file?
>>
>
