[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Elias Pschernig wrote:
> >
> > I would go with the first one personally, although the 2nd one looks
> > cleaner (but pollutes API with another struct). All other getter
> > functions we have in Allegro seem to return a single value - so to be
> > consistent with that, we also could use 4 separate functions - but
then,
> > we also should have 4 setter functions for that, so my vote stays #1.
Returning a struct is very different from how the rest of the current API
work, so I personally don't like it for that reason alone.
I would say that single getters are the most API consistent but passing
pointers is nicely symmetric with set_volume. In that case though, the
function should be prepared to deal with NULL meaning that no value has to
be returned for that parameter.
Are there other instances where the setter sets more than one thing and we
have separate getters? I don't think we do, so in that case I would go
with set_volume/get_volume symmetry.
One thing to consider: whatever we add to 4.2 will end up in the 4.3
compatibility layer, so consider what to do before adding features. That
said, I don't see a problem here.
> Another concern: on some drivers get_hardware_volume() will be
unavailable (on
> drivers where set_hardware_volume() does nothing). How should
> get_hardware_volume() behave in that case?
Set the returned volume to -1 to indicate `don't know', or just return 255
(maximum). Either of those sound like sensible return values to me (though
the first is a bit better, since the second is really a lie of sorts).
> Or int get_hardware_volume(int *digi, int* midi) which returns 0 on
> success.
Returning a value is good anyway. My gut reaction would be to have it
return `true' (ie, non-zero) on success, but on second thoughts 0 is
probably a better idea (there are many ways the code can fail, but only
one way it can succeed).
Evert