(Note that your code is not valid in Julia as you wrote it, missing
`type` for many declarations, etc.)
You could have
type Car{C,H,M,Y}
color::C
horsepower::H
model::M
year::Y
end
and set parameters to Void when they are not needed. This would enforce
what you require, and also seems to result in a smaller allocated size
when a parameter is Void.
Best,
Tamas
On Fri, Apr 15 2016, Anonymous wrote:
> So I have a pretty complex problem in designing my type data structure
> which I haven't been able to solve. Let's say I have an abstract car type:
>
> abstract AbstractCar
>
> now let's say I have the following possible features for a car:
>
> color
> horsepower
> model
> year
>
> Now I want to be able to create all possible composite concrete types
> containing any combination of these features, so that would be 2^4=16
> different composite types I need to define, and I would need to give them
> all names, so for example one of these 16 composite types would be
>
> CarHorseModel <: AbstractCar
> horsepower
> model
> end
>
> Obviously this is untenable since the number of possible types grows
> exponentially with the number of features. Thus a different approach that
> avoids this is to have one concrete type
>
> Car <: AbstractCar
> color
> horsepower
> model
> year
> end
>
> and then to set it up so that any features which I don't want to include
> are set to nothing. This avoids the problem above, but is
> messy and inelegant. However the bigger problem with it is that I want to
> have a container type for all my cars, call this container type Garage, and
> I want this container type to require that all cars in my garage have the
> same features. Thus in my original design with 16 separate composite
> types, I could simply set up my container type to be of the form
>
> type Garage{C <: AbstractCar}
> cars::Vector{C}
> end
>
> Unfortunately for the approach where I have a single Car type with all the
> features included and those I don't want set to nothing, there is no
> straight forward way to enforce this. The situation is further complicated
> because I then have various methods which I would like to dispatch on
> certain types of garages. For instance one method may only work for
> garages which contain cars which have a color feature, maybe another method
> only works on garages which have both a color feature and a year feature.
>
> What I would like is something that works like a parametric type, but
> instead of the parametric type changing the type of the fields, it
> effectively decides what field names are included in my composite type. So
> for instance Car{Color, Year} would produce the type
>
> Car{Color, Year} <: AbstractCar
> color::ASCIIString
> year::Int
> end
>
> However! A further problem, is that say I have a method which works on all
> garages which contain Car types which have a color feature, so that
> includes 2^3=8 different possible Garage types (all those which contain
> cars with a color feature), so this also grows exponentially with the
> number of features.
>
> What does everyone think is the right way to handle this problem
