Hi, I am newbie yet, but maybe julia could have an operator to wrap a
function call to specific type from specific module:
## module file
module modA
export TypeC, setx
type TypeC
x
end
function setx(c::TypeC, v::Any)
c.x = v
end
end
## other file
and on other file maybe we can call the setx like: objC.setx(v) and this
would be a wrap to setx(objC, v). I know we can define a function into the
type ... but this probably will down the performance and will go to
different way for the multiple dispatch.
PS:: again, sorry i'm a newbie julian :)
Ivan Ogasawara
El 13/01/2015 19:45, "Mauro" <[email protected]> escribió:
> > I would argue that this would be prohibited by the compiler as it could
> not
> > distinguish between
> > foo(x::Number) = 2
> > and
> > foo(x::Float64) = 3
>
> Yes it can:
>
> julia> foo(x::Number)=1
> foo (generic function with 1 method)
>
> julia> foo(x::Float64)=2
> foo (generic function with 2 methods)
>
> julia> foo(5)
> 1
>
> julia> foo(5.)
> 2
>
> > In the example I gave, count was allowed to be exported from my two
> modules
> > just by being defined by Base. Yet the two count's have different
> meanings
> > from each other and from the Base.count. On the other hand steadystate()
> > was not merged even though the end-result is the SAME: one would have two
> > methods that work on different types of arguments and do different
> things.
>
> I don't think it is good practice to add unrelated methods to generic
> functions in Base. A guide-line could be to check whether your methods
> matches up with the help text, if so, add it to Base.count otherwise
> not. If not, either give it a different name or do not export it, so
> the user has to fully qualify it MyMod.count.
>
> This is just my opinion but I suspect at least some share it.
>
