Re: [gtkmm] get method inconsistencies

On Sat, 2002-08-03 at 01:46, Andreas Holzmann wrote: 
> Ok, I checked the source again and ignored reference methods and
> stl-like methods. The List now contains the following methods:
>         Gtkmm
> treeiter.h  TreeRow   parent()   -> get_parent()

parent() returns an iterator, which is a bit like a reference, and it
should probably be like begin() and end(). 

> treemodelcolumn.h  TreeModelColumnRecord  size()  -> get_size()
size() is STL-like. 

>                                           types() -> get_types()
>                    TreeModelColumnBase    type()  -> get_type()
>                                           index() -> get_index()
> main.h  Main  instance()  -> get_instance()

That's returning a "reference" - specifically a pointer.

> table.h  Child  parent()  -> get_parent()

That's protected, and in a class that won't be derived from.
Let's not worry about it.

>         Gdkmm
> color.h  Color  red_p()   -> get_red_p()          ?? what does _p mean?

I don't know. They are like the other methods, but they multiply and divide
by 65535. It's a mystery to me.

>                 green_p() -> get_green_p()
>                 blue_p()  -> get_blue_p()

OK, let's change these to get_*_p() to be consistent with the get_*() methods.
> rgbcmap.h  RgbCmap  size()  -> get_size()

size() is STL-like. 

>         Glibmm
> thread.h  Thread      joinable() -> is_joinable()
>           Mutex       locked()   -> is_locked()
>           RecMutex    locked()   -> is_locked()
>           ReaderLock  locked()   -> is_locked()
>           WriterLock  locked()   -> is_locked()
> timeval.h   TimeVal  negative()  -> is_negative()
>                      valid()     -> is_valid()

This is Daniel's stuff. I suspect that he was trying to be STL-like, which 
is fair enough. I'd want his permission before changing it. If we can do it then
we will not freeze little-used parts of glibmm anyway.

> error.h              domain()    -> get_domain()
>                      code()      -> get_code()
>                      what()      -> get_message()    !! more descriptive

what() is meant to be the same as std::exception::what(). The others
should probably be consistent with that. 

> ustring.h   ustring  uppercase() -> get_uppercase()
>                      lowercase() -> get_lowercase()
>                      casefold()  -> get_casefold()

This is more like generate_uppercase(). It's not an accessor. I don't
think these should change. 

> quark.h     QueryQuark  id() -> get_id()

OK, but it's really an internals class.

Murray Cumming
murrayc usa net

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]