* On packages hierarchy @ 2014-07-28 13:41 Victor Porton 2014-07-28 16:03 ` Shark8 0 siblings, 1 reply; 8+ messages in thread From: Victor Porton @ 2014-07-28 13:41 UTC (permalink / raw) I am going to create the package RDF.Raptor.Iostream which would be Ada bindings around http://librdf.org/raptor/api/raptor2-section-iostream.html Afterward, I am going to create Ada IO stream (derived from Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and reversely RDF.Raptor.Iostream which encaspulates (wraps) Root_Stream_Type. Should packages which wrap each other be in child packages of RDF.Raptor.Iostream? I think no, because they do not require access to internals (private part) of RDF.Raptor.Iostream but child packages have access to private parts. So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names for these packages.) -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-28 13:41 On packages hierarchy Victor Porton @ 2014-07-28 16:03 ` Shark8 2014-07-28 16:35 ` Victor Porton 0 siblings, 1 reply; 8+ messages in thread From: Shark8 @ 2014-07-28 16:03 UTC (permalink / raw) On 28-Jul-14 07:41, Victor Porton wrote: > I am going to create the package RDF.Raptor.Iostream which would be Ada > bindings around > http://librdf.org/raptor/api/raptor2-section-iostream.html > > Afterward, I am going to create Ada IO stream (derived from > Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and > reversely RDF.Raptor.Iostream which encaspulates (wraps) Root_Stream_Type. > > Should packages which wrap each other be in child packages of > RDF.Raptor.Iostream? I think no, because they do not require access to > internals (private part) of RDF.Raptor.Iostream but child packages have > access to private parts. > > So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and > RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names for > these packages.) > Er, why? > Streams are a method to read or write any object to any medium, > and thus they are doubly generalized. This also means that you > are bounded by the most restrictive set of operations common to > all mediums. As an example, you cannot provide position control > in a general manner because not all transmission modes are > random-access (like receiving a radio-signal), and not all > streams are bi-directional (like a light-sensor). Why not just have a single stream type? Moreover, Ada's root-stream is abstract, so you can't have objects of that type. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-28 16:03 ` Shark8 @ 2014-07-28 16:35 ` Victor Porton 2014-07-28 23:24 ` Shark8 0 siblings, 1 reply; 8+ messages in thread From: Victor Porton @ 2014-07-28 16:35 UTC (permalink / raw) Shark8 wrote: > On 28-Jul-14 07:41, Victor Porton wrote: >> I am going to create the package RDF.Raptor.Iostream which would be Ada >> bindings around >> http://librdf.org/raptor/api/raptor2-section-iostream.html >> >> Afterward, I am going to create Ada IO stream (derived from >> Root_Stream_Type) which encaspulates (wraps) RDF.Raptor.Iostream and >> reversely RDF.Raptor.Iostream which encaspulates (wraps) >> Root_Stream_Type. >> >> Should packages which wrap each other be in child packages of >> RDF.Raptor.Iostream? I think no, because they do not require access to >> internals (private part) of RDF.Raptor.Iostream but child packages have >> access to private parts. >> >> So, should they be siblings, like RDF.Raptor.Iostream_To_Ada and >> RDF.Raptor.Iostream_From_Ada? (Also please help to conceive good names >> for these packages.) >> > > Er, why? > >> Streams are a method to read or write any object to any medium, >> and thus they are doubly generalized. This also means that you >> are bounded by the most restrictive set of operations common to >> all mediums. As an example, you cannot provide position control >> in a general manner because not all transmission modes are >> random-access (like receiving a radio-signal), and not all >> streams are bi-directional (like a light-sensor). > > Why not just have a single stream type? I want to make an interface to streams of Raptor C library. Because, as you say, we are to have a single stream type, this type should be well-interfaces with that "single" Ada stream class. > Moreover, Ada's root-stream is abstract, so you can't have objects of > that type. Well, I mean object of Root_Stream_Type'Class. -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-28 16:35 ` Victor Porton @ 2014-07-28 23:24 ` Shark8 2014-07-29 12:36 ` Victor Porton 0 siblings, 1 reply; 8+ messages in thread From: Shark8 @ 2014-07-28 23:24 UTC (permalink / raw) On 28-Jul-14 10:35, Victor Porton wrote: >> Why not just have a single stream type? > I want to make an interface to streams of Raptor C library. > > Because, as you say, we are to have a single stream type, this type should > be well-interfaces with that "single" Ada stream class. > >> >Moreover, Ada's root-stream is abstract, so you can't have objects of >> >that type. > Well, I mean object of Root_Stream_Type'Class. Again, why? Your Raptor-stream type /will/ be an concrete-instance of Root_stream_type, and a member of its class, won't it? I mean unless I'm completely misunderstanding you... Use Ada.Streams; Type Dave is new Root_Stream_Type with null record; overriding procedure Read (Stream : in out Dave; Item : out Stream_Element_Array; Last : out Stream_Element_Offset); procedure Write (Stream : in out Dave; Item : Stream_Element_Array); ---- Implementation: overriding procedure Read (Stream : in out Dave; Item : out Stream_Element_Array; Last : out Stream_Element_Offset) is null; -- Replace this with actual implementation. overriding procedure Write (Stream : in out Dave; Item : Stream_Element_Array) is null; -- Replace this with actual implementation. Perhaps reading the first and second posts on this thread will help you understand: http://computer-programming-forum.com/44-ada/07c6cd94dbb2d6b1.htm ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-28 23:24 ` Shark8 @ 2014-07-29 12:36 ` Victor Porton 2014-07-29 18:44 ` Shark8 0 siblings, 1 reply; 8+ messages in thread From: Victor Porton @ 2014-07-29 12:36 UTC (permalink / raw) Shark8 wrote: > On 28-Jul-14 10:35, Victor Porton wrote: >>> Why not just have a single stream type? >> I want to make an interface to streams of Raptor C library. >> >> Because, as you say, we are to have a single stream type, this type >> should be well-interfaces with that "single" Ada stream class. >> >>> >Moreover, Ada's root-stream is abstract, so you can't have objects of >>> >that type. >> Well, I mean object of Root_Stream_Type'Class. > > Again, why? > Your Raptor-stream type /will/ be an concrete-instance of > Root_stream_type, and a member of its class, won't it? I mean unless I'm > completely misunderstanding you... My raptor stream is derived from some my base class. Due no multiple type inheritance in Ada, it cannot be also derived from Root_Stream_Type. So I need a wrapper type. > Use Ada.Streams; > Type Dave is new Root_Stream_Type with null record; > > > overriding procedure Read > (Stream : in out Dave; > Item : out Stream_Element_Array; > Last : out Stream_Element_Offset); > > > procedure Write > (Stream : in out Dave; > Item : Stream_Element_Array); > > ---- Implementation: > > overriding procedure Read > (Stream : in out Dave; > Item : out Stream_Element_Array; > Last : out Stream_Element_Offset) > is null; -- Replace this with actual implementation. > > overriding procedure Write > (Stream : in out Dave; > Item : Stream_Element_Array) > is null; -- Replace this with actual implementation. > > Perhaps reading the first and second posts on this thread will help you > understand: > > http://computer-programming-forum.com/44-ada/07c6cd94dbb2d6b1.htm -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-29 12:36 ` Victor Porton @ 2014-07-29 18:44 ` Shark8 2014-07-29 19:42 ` Simon Wright 0 siblings, 1 reply; 8+ messages in thread From: Shark8 @ 2014-07-29 18:44 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-29 18:44 ` Shark8 @ 2014-07-29 19:42 ` Simon Wright 2014-07-29 21:26 ` Shark8 0 siblings, 1 reply; 8+ messages in thread From: Simon Wright @ 2014-07-29 19:42 UTC (permalink / raw) Shark8 <OneWingedShark@gmail.com> writes: > Function Convert is new Unchecked_Conversion > (Source => Light_Number, Target => GL_Enum); Given that Light_Number'Size is set to 3 (above), and is biased into the bargain, I don't see how this is going to work reliably? GNAT is certainly going to give you warnings about source & target having different sizes. I've often used a constant array (source) of target to do conversions like this. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: On packages hierarchy 2014-07-29 19:42 ` Simon Wright @ 2014-07-29 21:26 ` Shark8 0 siblings, 0 replies; 8+ messages in thread From: Shark8 @ 2014-07-29 21:26 UTC (permalink / raw) On 29-Jul-14 13:42, Simon Wright wrote: > Given that Light_Number'Size is set to 3 (above), and is biased into the > bargain, I don't see how this is going to work reliably? GNAT is > certainly going to give you warnings about source & target having > different sizes. It should work as expected: > testbed.adb:37:58: warning: size clause forces biased representation for "Light_Number" > testbed.adb:60:09: warning: types for unchecked conversion have different sizes > testbed.adb:60:09: warning: size of "Light_Number" is 3, size of "Gl_Enum" is 32 > testbed.adb:60:09: warning: source will be extended with 29 high order zero bits >... and ( from http://docs.adacore.com/gnat-unw-docs/html/gnat_rm_9.html#SEC485 ) > For example, suppose we have the declaration: > > > > type Small is range -7 .. -4; > for Small'Size use 2; > > Although the default size of type Small is 4, the Size clause is accepted by GNAT and > results in the following representation scheme: > > > > -7 is represented as 2#00# > -6 is represented as 2#01# > -5 is represented as 2#10# > -4 is represented as 2#11# Which means that: 1 would be represented ad 2#000# 2 would be represented ad 2#001# 3 would be represented ad 2#010# etc That internal representation *is* the zero-based indexing that OpenGL expects, and Convert (as shown above) extends its size with zero-bits. So there's no reason it shouldn't work. Granted it's going off a lot of implementation-defined behavior and your method of an array or my suggestion of a proper conversion-function expression-function would handle this in an implementation independent manner. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-07-29 21:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-28 13:41 On packages hierarchy Victor Porton 2014-07-28 16:03 ` Shark8 2014-07-28 16:35 ` Victor Porton 2014-07-28 23:24 ` Shark8 2014-07-29 12:36 ` Victor Porton 2014-07-29 18:44 ` Shark8 2014-07-29 19:42 ` Simon Wright 2014-07-29 21:26 ` Shark8
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox