Re: [AD] Function parameter ordering conventions

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Stephen Apostolopoulos wrote:
On Thu, 21 Jun 2007 11:33:01 +0300, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:

Eh, this is just asking for trouble! You want an interface to be
consistent: a new user using al_draw_bitmap should be right to
assume that
similar functions would work roughly the same (al_put_pixel is similar
enough, three parameter, one is a pointer). If the above syntax was
used,
he would have to make a round-trip to the manual for every single
function, because he'd never be sure what the parameter order would be
like - not good!
Not at all! As was pointed out, the convention then becomes that
primitives follow the pattern "position and geometry" followed by
"colour", while blit operations become "what to blit" followed by
"where and how". They are logically distinct.
It's a matter of how you read the code. If I draw a bitmap, I draw "a
bitmap" at "some location". If I draw a pixel, I set "a pixel
somewhere" to "a colour".


Position - Geometry - Colour	(primitive)
Position - Color		{pixel)
Bitmap   - Position - Mode	(bitmap)

This distinction is arbitrary - why should a bitmap follow a different convention from a colour? Does handling distinct 'objects' (bitmaps, colours, whatnot) differently convey some significant advantage to the developer or the user? If not, then the path of least resistance would be to treat them all the same:

I consider a bitmap to be an object and a colour to be an attribute. Also, in the case of a primitive (eg. a line), the geometry is considered to be a set of positions.

So your table will look like this:

Positions - Attribute		(primitive)
Position - Attribute		{pixel)
Object   - Position - Mode(*)	(bitmap)

* the mode may also be considered an attribute

AE.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/