Re: [AD] Function parameter ordering conventions

[Jon Rafkind <workmin@xxxxxxxxxx>]

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. For example al_put_pixel(color, dx, dy),
> 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
> Allegro, while not different enough to turn current users off of the new
> API.
>
> Since the API will be around for a while, and we want to get it right,
> I'm asking here for other people's opinions. How do you think the
> ordering should go?
>
>   
On some level I think its trivial what the ordering for parameters is as
long as its consistent. I have never liked that draw_sprite has a
different ordering of src/dst than blit. I happen to like the
draw_sprite ordering better, dst then src. If the parameters are going
to be consistent then they should be consistent in all contexts and in
some contexts there is no source bitmap, i.e. putpixel(dest,x,y,color)
as opposed to putting dest in some other position. Therefore I think
dest should *always* be the first parameter of any function that
modifies a bitmap.

Also, and this argument might not hold much weight, my scheme bindings
to allegro somewhat rely on the fact that dest is the first argument(
except for blit and friends ) and so I can do things like make a
function that assumes the first argument is implicitly 'screen'. So I
can do this:
(draw-sprite (screen) some-bitmap ...)
or
(draw-sprite-screen some-bitmap ...)

Which is only possible if dest is the first argument. For blit and those
functions I had to wrap them to achieve this affect and I could just do
that if the ordering is changed for all functions in 4.9, but I'd rather
not.