Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

C to Perl API implementation problems

by OeufMayo (Curate)
on May 05, 2001 at 00:23 UTC ( #78111=perlmeditation: print w/ replies, xml ) Need Help??

I am currently using for my job a full-blown Server-side javascript API to communicate to a Document Managment Database. This database uses a proprietary protocol to communcate with the client, and this protocol is available on CPAN.

What I'd like to do is to get rid of the Server-side javascript as it is really a complete hell to make something over 5000 lines work reliably in this language. So after browsing the documentation of the database, I came across the C and the language independent specifications of the API.
This API doesn't specify performance issues except for trivial (at least in perl) operations.

After a heavy rewriting of the mentionned module, I was able to implement successfully the key features of the API as a proof of concept. Now that I'm beginning the real work, the question is wether or not it is okay to stray from the original API specifications to fit a "normal" perl implementation. By "normal perl implementation", I'm thinking of the way one would write a module designed specifically for perl, relying on perl built-in funtionnalities.

As an example, there's a method which returns the length of a string. Should it be implemented or is it okay to just rely on perl's length function? I know that I could make a 'fake' length method call which will just send back the length of the string like:

sub length { my ($self, $string) = @_; return length $string; }
But I want to avoid promoting it in the documentation and not using it afterwards...

The other issue I'm facing is the error-handling. The API defines an 'Error' object which is sent back after each call to the server. I don't find it really easy to use and I was thinking of doing an error handling 'à la DBI' with the RaiseError function, leaving the user the ability to ignore it, but if it enables it, he doesn't have to handle the error object as it has been already processed by the internals.

My point is to know if it is considered good programming style to break one's API to fit the language it is implemented in, especially in Perl, where many shortcuts are available? Any thoughts on these various points would be more than welcome.

I eventually plan to release that module to the Perl community, to people who don't necessarily know the standard API. I'm trying to come up with a solution where a perl programmer would feel "at home" with the interface, but not scarying too much programmers who knew the API before.

Update: (hopefully) explained a bit more precisely my problem, thanks to crazyinsomniac and tilly.

And this is incidentally my first post to Meditations and my 100th node (my first question to SOPW for the 200th node)!

<kbd>--
my $OeufMayo = new PerlMonger::Paris({http => 'paris.mongueurs.net'});</kbd>

Comment on C to Perl API implementation problems
Download Code
Re (tilly) 1: C to Perl API implementation problems
by tilly (Archbishop) on May 05, 2001 at 16:28 UTC
    Who will be using this module?

    What will they be using it for?

    If you will be tossing new Perl people at the API who have never used the original, then you should definitely create as natural an API as you can.

    If you will be tossing people who are used to the old implementation of the API at the new, then there are good reasons to stick, at least in spirit, to the old.

    If you are going to spend a lot of time translating code from one language into another, making the correspondence fairly direct is probably a good idea.

    And you can always create a Perlish wrapper around something that you don't want to personally use.

    All that said, your actual suggestions for what to do with the API seem quite reasonable to me. What I would suggest is that you should create the smallest API that is convenient at the moment, and then start on the real work, adding things as they come up. Probably your length method would never happen. Your error mode probably will. And for things that are not very clear-cut, you will probably find a practical balance between what you need and what you can leave out...

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://78111]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (10)
As of 2014-08-30 13:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls