From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c31acc89d296bc62 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.68.MISMATCH!feeder.news-service.com!newsfeed.straub-nv.de!open-news-network.org!eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Design problem: generic package vs tagged subtype Date: Wed, 30 Jun 2010 20:23:43 +0100 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Wed, 30 Jun 2010 19:23:45 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="KCXegvZb5vh43D+f3BR6Ew"; logging-data="8122"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18F8ZMJfPgzIHJLahUN77C/7xrKL5G5Xu4=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin) Cancel-Lock: sha1:Y+kDtGDWjLQTk6NF5nlyb5A58xY= sha1:eFhSm+UJWZvtNwDgECv2z68QCHQ= Xref: g2news1.google.com comp.lang.ada:12052 Date: 2010-06-30T20:23:43+01:00 List-Id: Marek Janukowicz 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.