Michael,
I am much more of a newbie at Julia than you, but it seems to me that there
is a brute-force solution to this problem, namely define a few dozen
methods:
vcat(A1::CVXArray{T}, rest::AbstractArray{T}...)
vcat(A1::AbstractArray{T}, A2::CVXArray{T}, rest::AbstractArray{T}...)
vcat(A1::AbstractArray{T}, A2::AbstractArray{T}, A3::CVXArray{T},
rest::AbstractArray{T}...)
Maybe you could automate the generation of all of these with a Julia macro?
It would be rare for a user to have a vcat statement with more than a
handful of arguments, so you should be able to cover all the cases that
would ever occur in practice. You could define the 100th in this sequence
to throw an error, so that if any user ventured outside the range of cases
covered, at least he/she would know that something is wrong.
-- Steve
On Monday, August 4, 2014 4:10:36 PM UTC-4, Michael Grant wrote:
>
> Consider the following class hierarchy:
>
> module CVX
> immutable Scalar{T<:Number}
> abstract AbstractArray{T,N} <: Base.AbstractArray{Scalar{T},N}
> type Array{T,N} <: AbstractArray{T,N}
>
> Note in particular that CVX.Array{T,N} is an abstract array of Scalar{T}
> objects. For performance reasons, it is distinctly advantageous to avoid
> constructing Base.Array{Scalar{T},N} objects, so I'm overloading the
> various array manipulation operators to handle CVX.Array specially.
>
> But now consider cat(). What I would *like *to do is this:
>
> function cat( d::Integer, X::Union(Number,CVX.Scalar)... )
> function cat( d::Integer, X::Union(Number,CVX.Scalar,CVX.AbstractArray,
> Base.AbstractArray)... )
>
> The goal here is to override cat() for the case when there is at least one
> CVX object present. The problem here, of course, is that this overrides the
> catchall cat function, even if there are no CVX objects present:
>
> function cat( d::Integer, X::Any... )
>
> Is there an easy resolution to this problem? One solution is for Julia, or
> me, to define
>
> function cat( d::Integer, X::Union(Number,Base.AbstractArray)... )
> function cat( d::Integer, X::Number... )
>
> If I do it, I'd be reimplementing the generic method, in the first case
> at least, unless there is a way for me to link these new declarations
> directly to the existing implementations. Is there?
>
>
