Re: Nontrivial examples of C interface with Ada

[Ted Dennison <dennison@telepath.com>]

In article <o%2X4.118$_M2.45406@news.pacbell.net>,
  tmoran@bix.com wrote:
>   Even though your code now looks Ada-ish and has strong typing,
> exceptions, etc. you will still be operating at a very low, C-ish,
> level of abstraction,
...
> send some html text, and close it.  Do you really want the ugly
> details of socket handling, or do you want a procedure Open, procedure
> Put, and procedure Close?

That's a very good issue. I prefer to think of it as an issue of power.
All of those calls and parameters are there for a reason. Once you have
done a "mid-thick" binding, any further abstracting of the binding to
make it simpler is going to inevitably loose some of the power of the
original. Sure, it will be easier to use, but you won't be able to do as
much with it as a C coder could with the original. As they say, "power
comes with a price". In this case, the price is complexity in the
interface.

Sockets are a very good example. Sure, I could give it a Text_IO
interface. But then how do I set my sockets to non-blocking? How do I
adjust the mbufs? How do I send a message to multiple recepients? How do
I write a server that detects TCP/IP timeouts from clients? I could go
on and on here.

Now if I know ahead of time that the user of this facility is one
program that will never ever need any more than a certain set of
functionality, then making a thick binding that perfectly encompasses
that functionality is the Right Thing to do. But for a general purpose
binding to a C-interface library, I don't think abstracting away
functionality is the right idea at all (unless its functionality put in
to deal with C's limitations). Some power user is bound to come along
and want that weird feature I abstracted away. I don't want anyone using
my bindings to ever feel like they are stuck in some rounded-scissors
Ada ghetto.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.