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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx26.iad.POSTED!not-for-mail From: Shark8 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:30.0) Gecko/20100101 Thunderbird/30.0a1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: On packages hierarchy References: <4vuBv.121143$pu5.79212@fx27.iad> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Tue, 29 Jul 2014 18:44:23 UTC Organization: TeraNews.com Date: Tue, 29 Jul 2014 12:44:21 -0600 X-Received-Bytes: 5128 X-Received-Body-CRC: 2559321595 Xref: news.eternal-september.org comp.lang.ada:21340 Date: 2014-07-29T12:44:21-06:00 List-Id: On 29-Jul-14 06:36, Victor Porton wrote: > My raptor stream is derived from some my base class. Why? Is there some reason it needs to be exposed to the rest of the binding? If so, why does it need to be exposed separately from the derivation of Root_Stream_Type? This is to say given a derivation from Root_Stream_Type, why not have all parameters that need that type use that type? Is it because you want some uniformity of interface? In that case you could have the "base class" be an interface rather than a tagged type -- in fact you could do both: have a base-interface from which your normal raptor-types are rooted in an abstract type and have the limited types derive from the interface. Ex: package test is Type Raptor is limited interface; -- All common operations of all raptor-types go here. Procedure First_Stub(Input: Raptor) is abstract; Type Raptor_Base is abstract new Raptor with null record; Type Raptor_Stream is new Ada.Streams.Root_Stream_Type and Raptor with null record; Overriding Procedure First_Stub(Input: Raptor_Stream) is null; Overriding procedure Read (Stream : in out Raptor_Stream; Item : out Stream_Element_Array; Last : out Stream_Element_Offset) is null; Overriding procedure Write (Stream : in out Raptor_Stream; Item : Stream_Element_Array) is null; end test; > Due no multiple type inheritance in Ada, it cannot be also derived from > Root_Stream_Type. So I need a wrapper type. Why expose the raptor-stream at all? A lot of your problems seem to stem from trying to build from the low-level thin-binding to the high-level thick-binding while trying to keep [and expose] the low-level/thin-binding; try going the other way: *Design the high-level binding first, /then/ in the hidden implementation/bodies implement-and-use the low-level binding.* As a trivial example, consider OpenGL's gl_enum type and all the functions that use it with restrictions best used/expressed as full-blown types: package GL_Example is GL_MAX_LIGHTS : constant := 8; -- Light is a biased-representation of 1..8. -- May be implementation dependant, can be rectified with -- an expression function in the implementation call. Type Light_Number is range 1..GL_MAX_LIGHTS with size => 3; -- Safe_Float disallows non-numeric values. SubType Safe_Float is Float range Float'First..Float'Last; -- Enumeration of Open_GL's parameters for glLightf Type Light_Parameters is (SPOT_EXPONENT, SPOT_CUTOFF, CONSTANT_ATTENUATION, LINEAR_ATTENUATION, QUADRATIC_ATTENUATION); -- Thick Binding function. Procedure Light( Light_No : Light_Number; Parameter : Light_Parameters; Value : Safe_Float ) with Inline; end GL_Example; package body GL_Example is -- GL Types Type GL_Enum is new Interfaces.Unsigned_32; Type GL_Float is new Interfaces.IEEE_Float_32 Range Interfaces.IEEE_Float_32'Range; -- Conversions Function Convert is new Unchecked_Conversion (Source => Light_Number, Target => GL_Enum); Function Convert is new Unchecked_Conversion (Source => Light_Parameters, Target => GL_Enum); Function Convert is new Unchecked_Conversion (Source => Safe_Float, Target => GL_Float); -- Imported (thin-binding) functions procedure glLightf (light, pname : GL_Enum; param : GL_Float) with Import, Convention => stdcall, External_Name => "glLightf"; -- Thick-binding bodies Procedure Light (Light_No : Light_Number; Parameter : Light_Parameters; Value : Safe_Float ) is begin glLightf( Convert(Light_No), Convert(Parameter), Convert(Value) ); end Light; end GL_Example;