Re: If a routine should return two results, how should it be done?

["Dan'l Miller" <optikos@verizon.net>]

On Saturday, July 26, 2014 2:21:03 PM UTC-5, Peter Chapin wrote:
> On 2014-07-26 14:57, Victor Porton wrote:
> > I want to create a thick Ada binding for the following C function:
> > http://librdf.org/raptor/api/raptor2-section-uri.html#raptor-uri-uri-string-to-filename-fragment
> > char *              raptor_uri_uri_string_to_filename_fragment
> >                                                         (const unsigned char *uri_string,
> >                                                          unsigned char **fragment_p);
> > Which variant is better for this specific case: 1 or 3?
> 
> If you're creating a thick binding you don't need to limit yourself to
> the same collection of functions provided by the underlying library.
> You're in a position to define the types abstractly and write
> subprograms that expose the needed functionality without regard to the
> specific underlying functions.
> 
> I would expect a thick binding to merely use the underlying library to
> implement a higher level (cleaner, more abstract) interface. It's not
> about providing a binding to each underlying function one-to-one. That's
> a thin binding.

Yes, Victor, to be clear:  so far, you are writing a relatively thin binding, judging from the postings here at c.l.a that you have made.  As Dmitry & I have encouraged (and now apparently Peter as well), your thick binding would have a URI record or tagged record.  You would go through the entire underlying C library looking for OOish objects to represent as 1st-class citizens in your thick binding, not buried implicitly, scattered hither & yon in the C way of thinking.  You would decide how many URI syntaxes/domains that you want to support:  e.g., only URLs in WWW browsers?, not general URNs of, say, ISBNs?  If strictly URLs, then perhaps you would forego URI superclass entirely, since URNs for far-afield topics would be uninteresting to you.  If strictly URLs, then which protocols, e.g., all of them {http, https, file, ftp, ...}?  If only a subset, then perhaps the thick binding adds much value for treating URLs for http & https as having many http/https-specific behavior beyond mere string processing.  Likewise for files.  Likewise for ftp or any other protocol.  Perhaps protocol is the OO design to emphasize most and URIs or URLs or URNs are secondary or truly buried as mere parameters here & there.  In other words, take the C library and rethink it as if it did not exist, as if you were writing it from scratch.  What would you like to see the main entities be and how would you like them to behave most sanely?  Then, implement that OO API via the Raptor C library with a little or a lot of glue code between your Ada desired-state API and the (clunky?) Raptor C API's vision or lack thereof.

As Peter said:
...
> That's what makes them better. :)

Btw, URN examples far afield from WWW-browsers' URLs: http://en.wikipedia.org/wiki/Uniform_Resource_Name#Examples