Notwithstanding the explosion of possible types and the excellent advice
and insight provided by Tim, you can get the following to compile and run.
typealias Color ASCIIString
typealias Horsepower Float64
typealias Model ASCIIString
typealias Year Int
type Car{
C<:Union{Color,Void},
H<:Union{Horsepower,Void},
M<:Union{Model,Void},
Y<:Union{Year,Void}
}
color::C
horsepower::H
model::M
year::Y
end
# outer constructor
function Car(; color=nothing, horsepower=nothing, model=nothing,
year=nothing)
Car(color, horsepower, model, year)
end
# create cars by use keyword arguments in any order
myoldcar = Car(year=1967, horsepower=450.0, color="Red")
mynewcar = Car(year=2016, color="White")
# function operates on any homogeneous garage of cars with color and year
defined
function Count_Red_1963{C<:Color,H,M,Y<:Year}(garage::Vector{Car{C,H,M,Y}})
count = 0
for car in garage
if car.color == "Red" && car.year == 1963
count += 1
end
end
return count
end
garage_color_model_year = [ Car(color="Red", model="GTX", year=1963) for i
= 1:10 ]
# TODO: work out how to avoid messy conversion
garage_color_model_year =
convert(Vector{typeof(garage_color_model_year[1])}, garage_color_model_year)
garage_color_year = [ Car(color="Red", year=y) for y = 1960:1969 ]
garage_color_year = convert(Vector{typeof(garage_color_year[1])},
garage_color_year)
Count_Red_1963(garage_color_model_year)
Count_Red_1963(garage_color_year)
On Friday, April 15, 2016 at 1:54:17 PM UTC+10, 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
>
>
>
