Okay, so that matches the Java interface style, where you would then make
one function per variable you want to officially sanction as required.
One thing I didn't except from doing this is that if you do:
type OtherModule <: NNModule end
mod = OtherModule
getoutput(mod)
I was expecting an error within the method that 'output' doesn't exist for
'mod'. Instead I get:
ERROR: no method getoutput(Type{OtherModule})
which is a much nicer complaint.
The downside of the design is that now I have to duplicate the variable for
every type, but also make sure there's a function defined at top. However,
of the choices to make, it's probably the cleanest (though a macro might
save a little on typing).
Thanks for the help!
On Thursday, June 19, 2014 9:14:34 AM UTC-4, Jameson wrote:
>
> here is my recommended solution:
>
>
> abstract NNModule
> getoutput(nnm::NNModule) = nnm.output # <<-- add this line
>
> type LinearModule <: NNModule
> weight::Array{Float64}
> output::Array{Float64}
> end
>
> type SigmoidModule <: NNModule
> output::Array{Float64}
> end
>
>
> On Thu, Jun 19, 2014 at 8:18 AM, Abe Schneider <[email protected]
> <javascript:>> wrote:
>
>> I'm trying to figure out the best way to factor code that consists of
>> repeated modules which all share some common attributes.
>>
>> Specifically, if I have (very abbreviated from actual code):
>>
>> abstract NNModule
>>
>> type LinearModule <: NNModule
>> weight::Array{Float64}
>> output::Array{Float64}
>> end
>>
>> type SigmoidModule <: NNModule
>> output::Array{Float64}
>> end
>>
>> For both modules I need an 'output' variable. I know the idea of putting
>> variables in an abstract type has come up before. However, while it would
>> solve this problem, it is also not yet resolved (and may or may not
>> actually happy).
>>
>> Given that, two alternatives occur to me:
>> 1. Keep the current design and be okay with repeated code (difficult)
>> 2. Use a macro to create the repeated code for me
>>
>> Option (1) is certainly the easiest, and probably the one I'll stick with
>> for now. However, it seems error prone and (IMHO) produces ugly code.
>>
>> Option (2) has the problem that it can make what's actually happening
>> opaque and could potentially produce bugs that are difficult to track down.
>>
>> So my questions are:
>> (1) Have other people come across design issues like this before, and how
>> did they deal with it?
>> (2) Is there a macro out there already to accomplish this? After a quick
>> search, I found '@delegate' proposed as a solution for something like this,
>> but it was never officially merged. If not, any suggestions on how such a
>> macro should act/look?
>>
>>
>> As a side note, it would be great if Julia added properties to abstract
>> types. The current design gives something equivalent to Java's interfaces,
>> where most languages opt for mixins instead.
>>
>> Thanks!
>>
>
>
