comp.lang.ada
 help / color / mirror / Atom feed
From: Simon Wright <simon@pushface.org>
Subject: Re: Design problem: generic package vs tagged subtype
Date: Wed, 30 Jun 2010 20:23:43 +0100
Date: 2010-06-30T20:23:43+01:00	[thread overview]
Message-ID: <m2wrtgxr28.fsf@pushface.org> (raw)
In-Reply-To: i0g09r$da2$1@adenine.netfront.net

Marek Janukowicz <marek@janukowicz.net> writes:

> Hello everyone
>
> I'm struggling with some design problems in my project. To explain them I 
> need to give some background on my project, so please bear with me.
>
> I'm developing a library to wrap relational database records into Ada 
> objects (this kind of libraries are usually called "ORMs"). Generally I need 
> following entities:
> - some type corresponding to database table (I called it "Model"). It's 
> instances will hold records from that table, so it needs something to hold 
> database column values as attributes. Operations generally need to be 
> overridable.
> - something to map relationships between tables (associations)
>
> For Model I use a tagged type wrapped into generic package:
> generic
>    Tbl_Name : String;
>    type Attribute_Type is (<>);
>    type Attribute_Type_Array is array (Attribute_Type range <>) of 

Does this have to be an unconstrained array? If it wasn't, you wouldn't
need to worry about whether Attribute_Types covered the range of
Attribute_Type.

> Attribute_Type_Type;
>    Attribute_Types : Attribute_Type_Array;
> package Dar.Models.Base is
>             
>    type Model is abstract tagged limited record

   type Model is new Abstract_Base with ...

> ...
>
> For associations I also use a generic package:
> generic 
>    with package Source_Model is new Dar.Models.Base(<>);
>    with package Target_Model is new Dar.Models.Base(<>);
>    Foreign_Key : String;
> package Dar.Models.Associations is
>    function Find
> ...

... then the association can be between objects of type
Abstract_Base_Class'Class (though I don't see how you'd express the
actual relationship, not clear how Foreign_Key enters the picture).

>
>
> Here's where the trouble begins. Those Model subtypes tend to have quite a 
> lot of custom logic, some operations overriden etc. and I can't add this to 
> generic package instantiation, so I instantiate Dar.Models.Base inside 
> another package:
>
> package Dar_Test.Models.Users is
>    type Attribute_Type is (Id, Username, Email);
>    type Attribute_Type_Array is array (Attribute_Type range <>) of 
> Dar.Models.Attribute_Type_Type;
>    package Base is new Dar.Models.Base(
>       Tbl_Name => "authors",
>       Attribute_Type => Attribute_Type,
>       Attribute_Type_Array => Attribute_Type_Array,
>       Attribute_Types => (
>          Id => Attr_Integer,
>          Username => Attr_String,
>          Email => Attr_String
>       )
>    );
>    (some additional operations)
>    ...
>
> What I don't like is that I have additional operations in Users package, but 
> builtin operations in Users.Base (I want to make the design clean for 
> programmers using my library). I don't like parametrizing Associations with 
> Base instantiation. I think having just a tagged type (without a generic 
> package Dar.Models.Base) and extending it would be better, but I don't know 
> how to parametrize it with Attribute_Type type. 
>
> I hope my description is not too vague. If you have any thoughts or think my 
> approach is totally wrong please share your thoughts.
>
> Two additional (small) questions:
> 1. I'd like to replace type Attribute_Type_Array is array (Attribute_Type 
> range <>) of Attribute_Type_Type in Dar.Models.Base specification with ... 
> array (Attribute_Type'Range) ... to make sure full range of Attribute_Type 
> is specified, but the compiler complains. Is there any other way to ensure 
> that?

See above for suggestion. And why not just "array (Attribute_Type)"?

> 2. I have a type Attribute_Type_Type used to specify types of attributes 
> (Integer, Date, String etc.). I then have a variant record:
>   type Attribute_Value( Attr_Type : Attribute_Type_Type ) is
>       record
>          case Attr_Type is
>             when Attr_Date =>
>                Date_Value : APQ_Date;
>             when Attr_Time =>
>                Time_Value : APQ_Time;
>             ...
> Is there any way to use builtin types here instead of Attr_Date, 
> Attr_Integer, etc? Note that I need to specify type of each attribute in one 
> array.

I don't believe so.

As a side note I really dislike the name Attribute_Type_Type. It seems
to me that what you've called Attribute_Type is much more like a Name
than a Type.



  reply	other threads:[~2010-06-30 19:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-30 17:52 Design problem: generic package vs tagged subtype Marek Janukowicz
2010-06-30 19:23 ` Simon Wright [this message]
2010-06-30 22:33   ` Marek Janukowicz
2010-07-01  4:13     ` naming, was " tmoran
2010-07-01  9:49       ` J-P. Rosen
2010-07-01 15:48         ` Marcelo Coraça de Freitas
2010-07-01  5:57     ` Simon Wright
2010-07-01 18:30       ` Jeffrey R. Carter
2010-07-01 19:28         ` Simon Wright
2010-07-01 19:59           ` Jeffrey R. Carter
2010-07-01 21:14             ` Per Sandberg
2010-07-02  9:25         ` Stephen Leake
2010-07-02 10:50           ` Georg Bauhaus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox