Re: [Re: [gtkmm] status of memberfunctions of Glib::TimeVal ]
- From: Stephan Puchegger <puchs ap univie ac at>
- To: Murray Cumming <murrayc usa net>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [Re: [gtkmm] status of memberfunctions of Glib::TimeVal ]
- Date: Tue, 24 Sep 2002 11:55:40 +0200 (CEST)
Hi!
> I would like to avoid API addition as well as API breakage. It's all API
> change. We should only do it in emergencies.
This is also fine for me. Thats why I wrote to the mailing list and
asked about everyones opinion instead of entering a bug and writing a
patch without consulting the mailing list. You, Daniel and the others of
the gtkmm team have put an enormous effort into this library, and made
the library far more accessible than it C counterpart by using the
capabilities of C++. I just stated, that the API of TimeVal seems IMHO
incomplete. I did not assume, that everyone comes to the same conclusion.
I just did not understand why there is a memberfunction "substract" and
no memberfunction "add". I do understand, that "add_microseconds" is a
wrapper around the glib function, but I do not understand why there is a
memberfunction "add_milliseconds". There must be some reason for this, but
I have not been able to figure it out. If the design decision was a
tight wrapper around the glib functions without much more, because its a
rather seldom used class, its perfect - I just don't what the design
decision is.
And thats why I asked. If you want to keep it the way it is - no problem.
I really do not want to pester anyone with unwanted (API) changes -
especially not the maintainers of this great project. I am sorry if I did.
I just thought that those additions would make the class more useful.
May I just ask for a sentence what the official position on the class
TimeVal is? If its "keep it the way it is", I am not going to pester
any of you with that topic again.
Thanks for reading this
Stephan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]