Hello,
Jean-Philippe Barrette-LaPierre a écrit :
Le Janvier 17, 2006 11:55 AM, Jean-Philippe Barrette-LaPierre a écrit :
I looked into libs/sound library. I think I'll use it into SFLPhone, but
something bothers me. I see that you use a Utility class as a list. I don't
have any problems to use that kind of utility classes within an
application, because I admit that STL is not always simple to use. The
problem here is that I'm not sure that this utility classes should be
exposed within libs/sound.
Is the problem the fact that in order to use this library in another
app, you would have to learn the API provided by return values types (in
this case, StringList)?
I think everyone has a different way of perceiving what should be a simple
way of using lists, but everyone knows how to use std::list. I think that a
library should always expose the STL. It means that you can use a utility
class, but expose only the STL. After that, if a user wants to use a
convenient class, he could use one. But I think users will always use a
different utility class than you. So, instead of exposing your utility
class, you should expose the STL one.
Since StringList and String are subclasses of STL classes, we could
consider that the user of the API should know that she can use the STL
API with the returned values.
The user of this library alreay has to read the minimal documentation to
know the API, the fact that some returned values' types are subclasses
of STL types could be documented in the same place as well.
What do you think about this?
Here's a patch. You free to choose if you want to apply it.
I created ticket #327 to trac the evolution of this patch (
http://dev.openwengo.com/trac/openwengo/trac.cgi/ticket/327#preview ).
Thank you very much for this contribution.
All the best,
--
Julien Gilli
OpenWengo, the free and multiplatform VoIP client
http://dev.openwengo.com/
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
