Concrete types can't be subtyped because you need to know exactly how much 
memory space they occupy.

 -- John

On Jan 2, 2014, at 10:01 AM, Mauro <[email protected]> wrote:

> Only abstract types can be subtyped (and if I recall correctly this is
> going to stay that way for some type-theory-reason).
> 
> Further, at the moment abstract types cannot have fields, i.e. cannot be
> composite types.  However, this might change sometime, have a look at the
> issue:
> 
> https://github.com/JuliaLang/julia/issues/4935
> 
> (which is also referenced in the mailing list thread mentioned by tshort)
> 
> Now, all of this does not help with your quest, sorry, but it may be of
> some interest.
> 
> On Thu, 2014-01-02 at 16:23, Christian Groll wrote:
>> My interest lies in the implementation of types that are special cases of 
>> already existing composite types.
>> 
>> For example, I want to implement a type Portfolio, which is just a 
>> DataFrame with two additional requirements:
>> - all columns are of numeric type
>> - the sum of the entries in each row must be equal to 1
>> 
>> Or, I want to implement a type TimeSeries, which is just a DataFrame where 
>> the first column consists of dates. 
>> 
>> I think the way to go here would be to implement some type of constraint 
>> checking in the setindex! methods, although this would not prevent messing 
>> with the entries by way of directly setting the fields of the type. 
>> However, once there exist convenient getindex and setindex! methods, I hope 
>> that basically nobody would mess with the values directly, and complete 
>> immutability is not necessarily needed.
>> 
>> What I am trying to achieve is something that I think is called inheritance 
>> in other languages, where classes can simply be declared as subclasses to 
>> already existing classes. 
>> 
>> So the question is, whether something like this is possible in julia as 
>> well? As far as I get it, there is no way to declare a type to be a subtype 
>> of a composite type.
>> Or, if this is not possible, is there any way around, like for example 
>> declaring a type portfolio,
>> 
>> type Portfolio
>>   weights::DataVector{Float64}
>> end
>> 
>> where I can simply relate all setindex! methods to the respective methods 
>> of DataVector, adding constraint checks where necessary.
>> 
>> function Base.setindex!(pf::Portfolio,
>>                v::Any,
>>                col_ind::ColumnIndex)
>>    if check_constraints(pf, v, col_ind)
>>       setindex!(pf.weights, v, col_ind)
>>    else
>>       error("constraints not fulfilled.")
>>    end
>> end
>> 
>> However, I then would need some type of metaprogramming such that I do not 
>> have to implement all the numerous setindex! methods of DataVector from 
>> scratch up.
> 

Reply via email to