Are you sure you desperately need to dispatch methods on the features? The
fact that it's possible doesn't mean it's a good idea ;)
These days, when I run into types where a lot of fields are nil some of the
time; It's almost always better posed as a relational problem. What if the
features were tables/dicts, and membership indicated a specific
record/object has the feature and any extra feature info? It's difficult to
say from the information available, I'm not sure what problem you're really
trying to solve.
Peace
On Friday, April 15, 2016 at 5:54:17 AM UTC+2, 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
>
>
>
