Re: [gtk-list] RE: Radio_Menu_Item problem in 0.99.8



Steve Hosgood <iisteve@iiweeble.swan.ac.uk> writes:
> Has anyone got a rationale as to why I (as a user of a radio_menu_item) should
> have to know that I must call 'gtk_check_menu_item_set_state()' and cast my
> radio_menu_item with 'GTK_CHECK_MENU_ITEM()' in order to make it the default
> enabled button?
> 
> Surely in an object-orientated design I should be expected to call
> 'gtk_radio_menu_item_set_state()', and just pass the radio button to it without
> having to cast it to anything special?

Nope. The main principle working here is liskov substitution principle, which
states that you can use derived class object where base class object is
expected.

so, when we have function gtk_check_menu_item_set_state(GtkCheckMenuItem *o)
then you need to be able to use radiomenuitem in place of o parameter
in that function call. This is made possible with the cast.

the cast to base class pointer is equivalent of C++'s automatic upcast:
in C++: Gtk_Check_Menu_Item *cmi=rmi; <-- no cast, c++ handles it automatically
in C: GtkCheckMenuItem *cmi=GTK_CHECK_MENU_ITEM(rmi); <-- explicit cast, since 
                                              C does not make it automatically
after that you can pass cmi to everything that uses base class features.

Same happens with function calls:
C++: rmi->set_state(); <-- c++ casts rmi automatically
C: gtk_check_menu_item_set_state(GTK_CHECK_MENU_ITEM(rmi)) <-- explicit cast

The only problem with this is that users need to know about
inheritance relation between GtkCheckMenuItem and
GtkRadioMenuItem. But then again you need to know that in OO languages
to know that the set_state() function exists in radiomenuitem at all -
the function is not described in derived class.

> For that matter, even if I *was* using check_menu_items, why do I have to make
> an explicit cast with 'GTK_CHECK_MENU_ITEM()' in a call to
> 'gtk_check_menu_item_set_state()'? In an object-orientated design, shouldn't
> the 'gtk_check_menu_item_set_state()' routine do that for me? 

Its just different syntax issue. there's no way in C that the
gtk_check_menu_item_set_state could do it, if you want to keep
any type safety. (only way would be to have void* in the argument,
and obviously thats way worse than the current cast system, which can
check it in runtime instead of working incorrectly..)

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --



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