Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 1

Qt-jambi-interest Archive, August 2006
enums

Message 1 in thread

I was a bit disappointed to see that jambi choose to not use Java Enum 
objects, but went with integers instead.
I read the white paper where it said that that was because they could be 
used as flags.

Did anyone consider using the '...' argument for that?
This is basically an array of objects which can be looped over and 
compared to map to the int values in the conversion to C++.

Just an idea..
-- 
 [ signature omitted ]

Attachment: pgp3yozW2E780.pgp
Description: PGP signature

Message 2 in thread

Thomas Zander wrote:

>I was a bit disappointed to see that jambi choose to not use Java Enum 
>objects, but went with integers instead.
>I read the white paper where it said that that was because they could be 
>used as flags.
>
>Did anyone consider using the '...' argument for that?
>This is basically an array of objects which can be looped over and 
>compared to map to the int values in the conversion to C++.
>  
>

Hi, Thomas.

We were disappointed as well, but the Java enum construct is 
unfortunately incompatible with the way enums are used in C++, so 
currently we're stuck with integers. The nice part is that integers are 
quite light weight to use and pass between methods. ;-)

Thanks for you suggestion about using arrays for this, but in a lot of 
code that uses flags you will depend on bitwise operations that would be 
cumbersome and inefficient to implement with arrays.

Consider, for instance, the C++ code:

    flags = ~flags

Also, the flags issue is not the only incompatibility. Most of all, the 
fact that C++ enums are values and Java enums are ordinals make them 
conceptually different, so although they are called the same, they are 
not the same language mechanism.

-- Eskil
Message 3 in thread

On Friday 11 August 2006 09:39, Eskil A. Blomfeldt wrote:
> We were disappointed as well, but the Java enum construct is
> unfortunately incompatible with the way enums are used in C++, so
> currently we're stuck with integers. The nice part is that integers are
> quite light weight to use and pass between methods. ;-)

Not much more lightweight than 1 Enum or 1 Object[] (which itself is an 
object). ;-)


> Thanks for you suggestion about using arrays for this, but in a lot of
> code that uses flags you will depend on bitwise operations that would
> be cumbersome and inefficient to implement with arrays.

Thats one side of the issue. I personally have not seen any inheriting 
classes do much int based enum manipulation so I have the strong 
suspicion that the optimizations here are limited to Qt code.
The other side is that Enums in Java a safer.  Where I can cast a 
out-of-range int to an enum just fine, I can't do that in Java leading to 
more robust code.

The only place I really see Enum usage is in cases like
  foo.setAlignment(Qt.AlignTop | Qt.AlignLeft | Qt.AlignAbsolute);
which would actually look better using:
  foo.setAlignment(Qt.AlignTop, Qt.AlignLeft, Qt.AlignAbsolute);

> Consider, for instance, the C++ code:
>
>     flags = ~flags

Sure, but I definitely hope we can limit such amazingly ugly hacks to a 
minimum. I mean; Quick; find 10 people that can tell you what this does 
without lookup up docs! :)

> Also, the flags issue is not the only incompatibility. Most of all, the
> fact that C++ enums are values and Java enums are ordinals make them
> conceptually different, so although they are called the same, they are
> not the same language mechanism.

I appreciate that. I've been coding both languages for quite some time to 
know the hacks I can do in C++ and the beauty of Java where the language 
just refuses to give you enough rope to hang yourself.

In the end, I'm not convinced its impossible to clean up the external 
appearance of Qts C++ API in a way that it benefits from Javas real 
Enums.

The user has normal enums (non flags) that work just fine.  Then you have 
flags, which are easy to get to work with a bit of extra code in the 
generated classes like I explained above.
Find the 'cumbersome' cornercases and provide a couple of helper objects 
and you have a huge gain in appeal :)

-- 
 [ signature omitted ]

Attachment: pgpjRbpmaR22t.pgp
Description: PGP signature