[infinispan-dev] Fwd: [jgroups-dev] Incompatible change in 3.1.0

Dan Berindei dan.berindei at gmail.com
Tue Nov 29 07:47:13 EST 2011


On Tue, Nov 29, 2011 at 2:33 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> On 11/29/2011 11:59 AM, Bela Ban wrote:
>>
>> On 11/29/11 11:43 AM, Tristan Tarrant wrote:
>>> On 11/29/2011 11:28 AM, Bela Ban wrote:
>>>> Yes, I thought about this too, but then trashed the idea because enums
>>>> take up too much memory. Since an enum is a class, and an enum instance
>>>> is an instance (although a singleton / classloader instance), we have
>>> Why, you would just use the Enum when setting and getting, but otherwise
>>> just store your internal representation.
>>
>> Hmm, not a bad idea !  Although this way, you couldn't do
>> Message.setFlags((short)Message.OOB | Message.NO_FC), bitwise
>> operations, if OOB and NO_FC are enum instances...
> Why not use varargs here:
>
> Message.setFlags(Message.OOB, Message.NO_FC, ...);
>

You could also add a fluent interface that would look like this:

Message.setFlag(Message.OOB).setFlag(Message.NO_FC);

It looks a little worse than Tristan's suggestion but it won't create
a temporary array.

>>
>> Hmm, Message.setFlags() would look like this:
>>
>> public void setFlags(Flag flag) {
>>        flags |= (1<<  flag.ordinal());
>> }
>>
>>
>> I do like the idea, although no using enums all the way and converting
>> them to/from shorts internally kind of defeats the purpose of enums...
>>
>> Actually, I don't think this breaks any API, unless people use the byte
>> or short values directly.
>>
>> Hmm, what do you do whith Message.getFlags() ? It returns a short.
>> Although this can be represented with an enum, multiple values can't,
>> e.g. 'OOB | NO_FC' cannot be represented as an enum... Maybe getFlags()
>> should be deprecated then ?
>>

You can use an EnumSet for getFlags().

>> WDYT ? I'm willing to do this in 3.1, it's probably not worse than the
>> change from byte to short...
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list