Re: Wrapping C functions in Objective C proxy objects: naming convention?
Re: Wrapping C functions in Objective C proxy objects: naming convention?
- Subject: Re: Wrapping C functions in Objective C proxy objects: naming convention?
- From: "Michael Ash" <email@hidden>
- Date: Thu, 20 Nov 2008 12:15:52 -0500
On Thu, Nov 20, 2008 at 12:27 AM, Austin Ziegler <email@hidden> wrote:
> For a project that I'm working on, I have a need to write a code
> generator that will wrap certain kinds of C functions as Objective C
> messages on an Objective C proxy. Because I don't ultimately control
> the input, the parameters on the C functions may be poorly named. I'm
> looking for advice on how one might make useful object message names
> from C functions.
>
> The format of the functions in question is essentially like this[1]:
>
> int ns__add(double a, double b, double *result);
> int ns__sub(double a, double b, double *result);
> int ns__mul(double a, double b, double *result);
> int ns__div(double a, double b, double *result);
> int ns__pow(double a, double b, double *result);
>
> The int return is a status code; the result of the operation is in
> double* result. If there's an error in the operation. (The status code
> may be ignorable, in which case part of my following question is
> answered; I'm still researching this part. I suspect that it is best
> not ignored.)
>
> Anyway, the problem is how I should convert this function with poorly
> named parameters into a proxy object and messages?
>
> The options that I've come up with (expressed in terms of use) follow.
> They're all expressed in terms of an object ns__CalcProxy:
>
> ns__CalcProxy calc = [[ns__CalcProxy alloc] init];
> double a, b, result;
> int status;
>
> result = [calc addDoubleA:a withDoubleB:b]; // #1
> result = [calc addDoubleA:a withDoubleB:b status:&status]; // #2
> status = [calc addDoubleA:a withDoubleB:b returning:&result]; // #3
Please excuse a foolish question, but.... Why wrap this in Objective-C
at all? Looks like the resulting ObjC code is essentially the same,
except uglier, slower, and harder to use. Why not just keep the C and
use it directly?
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden