Just to add to Spencer's answer: Is there a particular reason to have your
function arguments have type annotations at all in the function definition?
You could just write
function f(x)
y= x[3:5] # or whatever
z = length(x)
end
and now someone could call f with any kind of object that supports indexing
and "length" and it will work. This is "duck-typing", if you're familiar
with that term, and is the dominant paradigm in Julia precisely since it
makes generic programming easier.
On Wednesday, October 21, 2015 at 11:50:32 AM UTC-4, Spencer Russell wrote:
>
> On Wed, Oct 21, 2015, at 11:38 AM, Gabriel Gellner wrote:
>
> No that is a good point. Often you can use an iterator where an explicit
> array would also work. The issue I guess is that this puts the burden on
> the developer to always write generic code that when you would want to
> accept an Array you also need to accept a iterator like LinSpace.
>
> Maybe this is easier to do than I currently understand?
>
>
> In general you can just make your function accept an AbstractVector (or
> more generally AbstractArray) and things will just work. If there are
> places where Ranges, LinSpaces, etc. aren't behaving as proper arrays
> then I think those are generally good candidates for Issues (or even
> better, PRs).
>
> As a related aside:
> For efficiency you'll still want to use a concrete Vector field if you're
> defining your own types, but luckily there seems to be a convert method
> defined so you can do:
>
> type MyArr{T}
> x::Vector{T}
> end
>
> a = MyArr{Int64}(1:4)
>
> And it will auto-convert the range to an array for storage in your type.
>
> -s
>
