* 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