Gtk constants in Java

Maurizio De Cecco maurizio@mandrakesoft.com
Mon Jul 17 02:40:00 GMT 2000


Oskar Liljeblad <osk@hem.passagen.se> writes:

> I consider this a bit over-kill. However it has an advantage: type checking.


Why it is an overkill ?

After all, you just add one object for each constant, i don't see the
overhead problem; by the way, the int constant inside the object is
useless (other than documentation), since then you use object identity
to check the constant, not object equivalence (i.e. '==').

Is there really a performance/overhead problem in this case ?

Shouldn't readibility and type safeness more important in this case ?

I mean, do we really have an inner loop test 100 thousands type an enum
value, so that inlining the check is essential ?

> Something the author of Java-Gnome probably didn't think of is that
> flags may need to be OR'ed. The above wouldn't work if GtkArrowType's
> could be combined. In my opinion this makes this alternative unusable.

Well, if a constant is an object, than you use arrays or collection Sets as OR;
that is surely more overhead, but ...

OK, Sets will be less efficent; about readability, uh, it depends on the point
of view; for example (imaginary constants and functions):

   GtkOption[] opts = {GtkOption.8BIT, GtkOption.GREY, GtkOption.SVGA};

   GtkFrobScreen(opts);

Or:

   int opts = GtkOption.8BIT | GtkOption.GREY | GtkOption.SVGA;

   GtkFrobScreen(opts);

I understand that allocating an array imply more work than doing an OR between 
constants, a bigger difference than than inlining or not the above check.

But also here, i would check if performance is really an issue.

Maurizio































> 1. All constants are kept in a "static" class called Gtk
>    (Gtk.ARROW_UP, Gtk.ARROW_DOWN, ..). This is probably the
>    most "economic" solution.

As said by an other post, this is not extensible

> 2. One "static" class for each flag/enum-set, with int-constants as
>    the first alternative above (GtkArrowType.UP, GtkArrowType.DOWN,
>    ..). This is the nicest solution IMHO. It is also efficient if
>    the run-time needn't keep the classes in memory. (Is this true?)
> 
> 3. Constants are kept in the object class which they belong to.
>    I.e. GTK_BUTTON_IGNORED from the GtkButtonAction flag-set would
>    be GtkButton.IGNORED in Java. This would not work for all
>    enumerations, because they are used in more than one gtk
>    widget. An example is the GtkMatchType enumeration (there is no
>    GtkMatch). This could be solved by putting these ambiguous constants
>    in a class Gtk (like alt. 2), or putting then in all classes they
>    apply to.
> 
> I would like to know what you think about these alternatives.
> 
> Oskar Liljeblad (osk@hem.passagen.se)
> 

-- 
Maurizio De Cecco
MandrakeSoft 		http://www.mandrakesoft.com/


More information about the Java mailing list