Rudiger,
Perhaps, though not guaranteed. I would presume that each value in the enum
set would have a numeric value matching the ordinal as defined in Session.
John
On Mon, Sep 26, 2011 at 10:30 AM, Rüdiger zu Dohna
<ruediger.dohna_at_1und1.de>wrote:
> John,
>
> the valueOf(int) method is a synonym for values()[i], isn't it?
>
> And should we really declare this method:
> > Connection.createSession(**boolean,EnumClassName);
>
> The "transacted" boolean is redundant to the EnumValue SESSION_TRANSACTED,
> isn't it?
>
>
> Rüdiger
>
>
> On 26.09.2011 11:44, John D. Ament wrote:
>
>> Thanks Rudiger for pushing this. I was trying to avoid "force" but
>> figure I should pitch in; here's my attempt at clarifying my request,
>> hopefully I don't mess it up :-)
>>
>> The way I see it, for backwards compatibility, we leave the int method
>> in place:
>>
>> Connection.createSession(**boolean,int);
>>
>> In the enum we introduce a valueOf method, taking the int value as an
>> argument and returning the enum. We then add the following methods, and
>> mark the current int method as deprecated:
>>
>> Connection.createSession(**boolean,EnumClassName);
>> Connection.createSession(); //for use in EE
>> Connection.createSession(**EnumClassName);
>>
>> We're not introducing four enums, we're introducing one enum that has 4
>> values within it. The valueOf method helps us bridge the old way for
>> calling and the new one. Here's how I figure each method would be used:
>>
>> Connection.createSession(**boolean,int);
>> just returns createSession(boolean, EnumClassName.valueOf(int));
>>
>> Connection.createSession();
>> Just creates a default transacted session for EE use, with behavior in
>> EE and SE as defined by Nigel below.
>>
>> Connection.createSession(**EnumClassName);
>> Transactional state as noted by Nigel above.
>>
>> Connection.createSession(**boolean,EnumClassName);
>> Same behavior as today.
>>
>> John
>>
>>
>> On Mon, Sep 26, 2011 at 2:55 AM, Rüdiger zu Dohna
>> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.**de<ruediger.dohna_at_1und1.de>>>
>> wrote:
>>
>> On 23.09.2011 16:34, Nigel Deakin wrote:
>>
>> ...further new method ... Session createSession()
>> Any comments?
>>
>>
>> Exquisit simplification... +1
>>
>>
>> Separately, John suggested:
>>
>> Could your spec change perhaps use an enum to describe the
>> sessionMode as well?
>>
>>
>> If this has been a new API then an enum would have definitely
>> been the right thing, and my initial reaction was to agree
>> with John's proposal. However another EG member has pointed out
>> that since we already have four static constants
>> (Session.AUTO_ACKNOWLEDGE etc) adding four enum values which
>> would effectively duplicate these would unnecessarily
>> complicate the API. I'm therefore inclined to stick with the
>> existing four static constants. Does anyone else have any
>> particular views on this?
>>
>>
>> I'd prefer the enum, too. The old constants could be marked as
>> deprecated and eventually removed. All other methods that take such
>> an int, would have to be marked as deprecated as well and get a new
>> variant with the enum. I'm all for cleaning up APIs!
>>
>>
>>