Re: [AD] Function parameter ordering conventions

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Wednesday 20 June 2007 23:15, Trent Gamblin wrote:
> Elias and I were discussing how function parameters should be ordered
> with the new API. I thought (and I think Elias agreed) that the order
> function(src, src_params, dst, dst_params) is the most natural, and that
> flags should go last.

I agree with source first and destination second and flags last, but with 
some footnotes.
There are a few cases (the blit functions come to mind) where the API 
proposal (Bob's version anyway) has the mode as the first parameter. This 
put me off at first (on the basis of flags last), but there is a rationale 
for it: it isn't a flag in the sense that it *modifies* the behavior, it 
is a mode that *defines* the behavior. Having played with this a bit, I 
actually found that I did like both this distinction and ordering. I'd 
recommend playing with it for a bit. As I said, my initial reaction 
was "eeew! Flags should go last!" so don't dismiss the idea from the 
outset on those grounds.

To turn that 180 degrees around, I don't think I like the strict 
ordering "src, src_params, dst, dst_params", prefering "src, dst, 
src_params, dst_params" in general. However, this possibly depends on 
whatis more natural in a given circumstance.

> For example al_put_pixel(color, dx, dy), 

Don't like this ordering for put_pixel one bit, possibly because I've never 
seen a put pixel function anywhere that used this ordering ever. If that's 
right, I would recommend against deviating from the norm.

> al_draw_bitmap(picture, dx, dy, flags), and
> al_draw_scaled_bitmap(picture, sx, sy, sw, sh, dx, dy, dw, dh, flags).
> I think this style is more consistant than the current one used in

stretch_blit is already like that in 4.2. Do we get to bring up implicit 
destination arguments again? ;)

In general, I would recommend to stick as close to Bob's proposed API as 
possible, even if that may be getting a bit old as well by now.

Evert