Prev: Announce : Release of gnatgpr 0.32, access to GPR project information.
Next: Make specific warning error with gnat?
From: tmoran on 1 Jul 2010 00:13 > That's one of the things I dislike in Ada - everything (types, variables, > packages, operations) follows exactly the same naming convention and doesn't > use any special character/whatever to distinguish between them, so you run > out of good names in no time... You are welcome to invent your own prefixes or suffixes. Words in English often don't use those but depend on context and syntax to disambiguate. The fish in the bowl was one of the fish in the stream, but I decided to go fish in the stream and tell this fish story.
From: J-P. Rosen on 1 Jul 2010 05:49 tmoran(a)acm.org a �crit : >> That's one of the things I dislike in Ada - everything (types, variables, >> packages, operations) follows exactly the same naming convention and doesn't >> use any special character/whatever to distinguish between them, so you run >> out of good names in no time... > You are welcome to invent your own prefixes or suffixes. .... and have your naming rules checked by AdaControl (sorry, couldn't resist) ;-) -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Marcelo Coraça de Freitas on 1 Jul 2010 11:48
First I'd like to say I am sorry if my text writing isn't quite clear. I am not a native english speaker and I haven't spoken in this language for quite a while now. I have come through some of those problems when I was design KOW_Ent (another Ada ORM, which is MGPL and is based on APQ-Provider which is a database connection pool implemented using APQ). I decided to use tagged types all over the place (the only generic package was for building queries and returning vectors of objects, which is being replaced by a non-generic implenentation... well, I am getting off topic now.. hehe). Each persistent type extends KOW_Ent.Entity_Type (which already has an ID, a field for storing filtering tags (in the web sence) and the original entity tag (it is possible to extend a type further). The columns are represented by the KOW_Ent.Entity_Property_Type. Each data type is represented by it's very own Entity_Property_Type implementation which holds access to a function to get the data from the object and a procedure that sets it. For the engine to work it is needed to register the entity type and it's properties: An example of code generated by a tool created to easy the development of kow_ent based applications is: KOW_Ent.Entity_Registry.Register( Entity_Tag => teca.Entities.Content_Entity'Tag, Table_Name => "teca_contents", Id_Generator => null, Factory => The_Content_Entity_Factory'Access ); KOW_Ent.Entity_Registry.Add_Property( Entity_Tag => teca.entities.Content_Entity'Tag, Property => KOW_Ent.Properties.New_UString_Property( Column_Name => "title", Getter => teca.Entities.Content_Entity_title_hlp.getter'Access, Setter => teca.Entities.Content_Entity_title_hlp.setter'Access ,Length => 255 ) ); By the way, the factory is used by the web interface for handling database data which is part of the KOW_View-Entities module. The data loading process is done by the KOW_Ent.Load procedure: procedure Load( Entity : in out Entity_Type'Class; ID : in ID_Type ); It then queries the registry and load the data - that will come from different tables when you extend another existing entity type. The store procedure works basically the same. I hope my 50 cents can help you in your task. Regards, -- Marcelo C. de Freitas http://framework.kow.com.br |