Effective use of derived types

Effective use of derived types

[Victor Porton]

I write an Ada library (in fact thick bindings to a C library), which (among 
other) deals with some strings, including URIs.

Should I introduce new type for URI strings?

type URI_String is new String;

Or it is an overkill?

-- 
Victor Porton - http://portonvictor.org

Re: Effective use of derived types

[Dmitry A. Kazakov]

On Fri, 25 Jul 2014 19:40:27 +0300, Victor Porton wrote:

> I write an Ada library (in fact thick bindings to a C library), which (among 
> other) deals with some strings, including URIs.
> 
> Should I introduce new type for URI strings?

Yes.

> type URI_String is new String;

No.

URI is not a string. It has a textual representation, which is a string
(one of many types of strings). If you want a type for URI it should keep
its fields. You will have functions alike to attributes Value and Image to
convert URI from and to String.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Effective use of derived types

[Victor Porton]

Dmitry A. Kazakov wrote:

> On Fri, 25 Jul 2014 19:40:27 +0300, Victor Porton wrote:
> 
>> I write an Ada library (in fact thick bindings to a C library), which
>> (among other) deals with some strings, including URIs.
>> 
>> Should I introduce new type for URI strings?
> 
> Yes.
> 
>> type URI_String is new String;
> 
> No.
> 
> URI is not a string. It has a textual representation, which is a string
> (one of many types of strings). If you want a type for URI it should keep
> its fields. You will have functions alike to attributes Value and Image to
> convert URI from and to String.

I am writing thick Ada bindings to a C library which has URI objects.

But the C implementation of URI sometimes uses strings (say to initialize a 
new URI object from a string).

So my question remains in force.

-- 
Victor Porton - http://portonvictor.org

Re: Effective use of derived types

[Dan'l Miller]

On Friday, July 25, 2014 1:00:06 PM UTC-5, Victor Porton wrote:
> Dmitry A. Kazakov wrote:
> > On Fri, 25 Jul 2014 19:40:27 +0300, Victor Porton wrote:
> >> I write an Ada library (in fact thick bindings to a C library), which
> >> (among other) deals with some strings, including URIs.
> >> Should I introduce new type for URI strings?
> 
> > Yes.
> 
> >> type URI_String is new String;
> 
> > No.
> 
> > URI is not a string. It has a textual representation, which is a string
> > (one of many types of strings). If you want a type for URI it should keep
> > its fields. You will have functions alike to attributes Value and Image to
> > convert URI from and to String.

Dmitry, at some shallow level your statements are trivially correct, but are quite misleading as stated if taken to heart deeply.  Victor is not asking whether URI should be a tagged record; of course it should.  Victor is not asking whether that URI tagged record should have its package associated functions taking the URI tagged record as their first parameter; of course it should.  Instead, Victor is asking whether the URI_string member of the URI tagged record (and return/out-bound value of dispatched functions & procedures thereof) should be a subtype of string or not.

I say of course URI should be a subtype of string in Ada2012 so that it can Dynamic_Predicate post-conditions that enforce the regular expression that URIs must obey.  A(t least one) function that takes the URI tagged record as its first parameter should return that constant URI_string subtype (not general Ada.string) so that app-domain code that uses Victor's URI tagged record is informed of these regular-expression restrictions.

Perhaps the bigger question is:  would the URI'Class include URL and URN?  If so, would the URL and URN tagged records have URL_string and URN_string subtypes of URI_string?  How would overriding URL's dispatched function & procedures interact with the desire to use the narrower URL_string and URN_string in those URL & URN contexts instead of the (a-little-too-permissive-)URI_string.  Using too-permissive-URI_string is nearly as bad as using the vastly-too-permissive-Ada.string.  A good design will hinge on the proper finessing of these URL and URN finer points.  Btw, even more so when one considers the vast variety of URNs & their respective syntaxes  (e.g., ISBNs, IETF RFC, ASN.1 OID)

> I am writing thick Ada bindings to a C library which has URI objects.
> 
> But the C implementation of URI sometimes uses strings (say to initialize a 
> new URI object from a string).
> 
> So my question remains in force.

Good for you, Victor.

I would add that the lesson here is that as a designer you should ask yourself:  does this thing A-prime have a fundamentally different nature (to the beast) than similar thing A?  For example where Ada.string is thing A and URI_string is thing A-prime, does string have the ability to contain a different character-set than URI_string (or the same character-set but with escaping mechanism to partition the valuespace)?  Ada.string can contain an arbitrary quantity of whitespace, whereas URI_string cannot have spaces in domain-names of URLs nor to the left of the // in the protocol prefix.  Hence, that whitespace prohibition goes into the Dynamic_Predicate post-condition of URI_string's declaration of subtype of Ada.string.  Likewise, for all the other regular-expression characteristics that narrow URI_string from general-purpose Ada.string.

Re: Effective use of derived types

[Dmitry A. Kazakov]

On Fri, 25 Jul 2014 11:40:58 -0700 (PDT), Dan'l Miller wrote:

> On Friday, July 25, 2014 1:00:06 PM UTC-5, Victor Porton wrote:
>> Dmitry A. Kazakov wrote:
>>> On Fri, 25 Jul 2014 19:40:27 +0300, Victor Porton wrote:
>>>> I write an Ada library (in fact thick bindings to a C library), which
>>>> (among other) deals with some strings, including URIs.
>>>> Should I introduce new type for URI strings?
>> 
>>> Yes.
>> 
>>>> type URI_String is new String;
>> 
>>> No.
>> 
>>> URI is not a string. It has a textual representation, which is a string
>>> (one of many types of strings). If you want a type for URI it should keep
>>> its fields. You will have functions alike to attributes Value and Image to
>>> convert URI from and to String.
> 
> Dmitry, at some shallow level your statements are trivially correct, but
> are quite misleading as stated if taken to heart deeply.  Victor is not
> asking whether URI should be a tagged record; of course it should.  Victor
> is not asking whether that URI tagged record should have its package
> associated functions taking the URI tagged record as their first
> parameter; of course it should.  Instead, Victor is asking whether the
> URI_string member of the URI tagged record (and return/out-bound value of
> dispatched functions & procedures thereof) should be a subtype of string
> or not.

The question was about thick bindings. The difference between thin and
thick bindings is in particular that in the latter you use Ada types for
arguments and results and C types in the former. In both cases the answer
is no, URI should never be String. For thin bindings it would likely be
char_array for an input and chars_ptr for an output. For thick bindings it
should be a properly designed type, not necessarily tagged.

(Many Ada bindings are semi-thick, they use Boolean and String where
appropriate and remain thin in other cases.)

> I say of course URI should be a subtype of string in Ada2012 so that it
> can Dynamic_Predicate post-conditions that enforce the regular expression
> that URIs must obey.

I doubt that were realistic. In any case the amount of work required to
design such a predicate would be far bigger than in the case of a proper
type. Usefulness would be near to zero. It is like designing a predicate
that yields true of the string contains a valid Ada program...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Effective use of derived types

[Dan'l Miller]

On Friday, July 25, 2014 2:33:15 PM UTC-5, Dmitry A. Kazakov wrote:
> On Fri, 25 Jul 2014 11:40:58 -0700 (PDT), Dan'l Miller wrote:
> > I say of course URI should be a subtype of string in Ada2012 so that it
> > can Dynamic_Predicate post-conditions that enforce the regular expression
> > that URIs must obey.
> 
> I doubt that were realistic. In any case the amount of work required to
> design such a predicate would be far bigger than in the case of a proper
> type. Usefulness would be near to zero.

The Dynamic_Predicate could raise an exception for a URI string (e.g., a URL_string) that does not conform to the regular expression that all supported URIs (e.g., URLs) are required to obey.  Or are raising exceptions in Dmitry's same Bucket-of-Uselessness* as finite-state machines?

* some of which, other programmers find to be actually useful

> It is like designing a predicate
> that yields true of the string contains a valid Ada program...

mere hyperbole that does not answer Victor's question

Re: Effective use of derived types

[Shark8]

On 25-Jul-14 10:40, Victor Porton wrote:
> I write an Ada library (in fact thick bindings to a C library), which (among
> other) deals with some strings, including URIs.
>
> Should I introduce new type for URI strings?
>
> type URI_String is new String;
>
> Or it is an overkill?


It depends on how you are going to use it.
One thing to keep in mind us that you cannot overload on subtypes, but 
can on new [derived] types.

Example:

-- The Compiler cannot distinguish which function should be called.
Function "+"(Left, Right : Natural) return Natural;
Function "+"(Left, Right : Integer) return Integer;

-- If you're dealing with new types the compiler can.
Type ShortEx is new Integer range 0..128;
Function "+"(Left, Right : Natural) return Natural;
Function "+"(Left, Right : ShortEx) return ShortEx;

-----------------------
--  Strings Example  --
-----------------------

     Package Tax is
         Type Tax_ID(<>) is private;

         -- SSN format: ###-##-####
         Subtype Social_Security_Number is String(1..11)
         with Dynamic_Predicate =>
           (for all Index in Social_Security_Number'Range =>
              (case Index is
                 when 4|7 => Social_Security_Number(Index) = '-',
               when others => Social_Security_Number(Index) in '0'..'9'
              )
           );

         -- EIN format: ##-#######
         Subtype EIN is String(1..10)
         with Dynamic_Predicate =>
           (for all Index in Social_Security_Number'Range =>
              (case Index is
                 when 3 => EIN(Index) = '-',
               when others => EIN(Index) in '0'..'9'
              )
           );

     Private
         Type Tax_ID is new String
           with Type_Invariant =>
             String(Tax_ID) in EIN or
             String(Tax_ID) in Social_Security_Number or
             raise Constraint_Error;
     End Tax;