I think it is fine that the type of the argument determines the behavior here. Having "type" in the name would be a bit like having `fabs(x::Float64)`.
2015-02-27 15:21 GMT-05:00 Jutho <[email protected]>: > But I wouldn't overload real; real is for the real value of a value, not > for the real type. Maybe something like realtype , or typereal if we want > to go with the other type... functions. > > Op vrijdag 27 februari 2015 21:18:34 UTC+1 schreef Andreas Noack: >> >> I'd like to have something like this. >> >> 2015-02-27 15:02 GMT-05:00 Jutho <[email protected]>: >> >> Or in this particular case, maybe their should be some functionality like >>> that in Base, or at least in Base.LinAlg, where is often necessary to mix >>> complex variables and real variables of the same type used to build to >>> complex variables. >>> >>> Op donderdag 26 februari 2015 08:10:35 UTC+1 schreef Sheehan Olver: >>>> >>>> Maybe a better alternative is to create an internal function with the >>>> same name: >>>> >>>> real(v…)=Base.real(v…) >>>> real{T<:Real}(::Type{Complex{T}})=T >>>> real{T<:Real}(::Type{T})=T >>>> >>>> This will avoid the override leaking from the package. >>>> >>>> >>>> >>>> >>>> > On 26 Feb 2015, at 6:07 pm, Sheehan Olver <[email protected]> >>>> wrote: >>>> > >>>> > I think this is a case where I know the answer but pretending I don’t >>>> :) >>>> > >>>> > >>>> > >>>> >> On 26 Feb 2015, at 6:06 pm, Ivar Nesje <[email protected]> wrote: >>>> >> >>>> >> We have seen quite a few instances where Base functions were >>>> extended with methods without restriction to non-Base types, and it caused >>>> problems when Julia was updated. >>>> >> >>>> >> Is randomly breaking in new versions of Julia your style? >>>> > >>>> >>>> >>
