Re: [hibernate-dev] Master

2016-04-15 Thread Sanne Grinovero
On 15 April 2016 at 17:10, Steve Ebersole wrote: > That's not the intent. Users do deal with Session or StatelessSession. > SharedSessionContract simply exists as a convenience for us to make sure > Session and StatelessSession implement some of the same signatures. Ok, I

Re: [hibernate-dev] Master

2016-04-15 Thread Steve Ebersole
That's not the intent. Users do deal with Session or StatelessSession. SharedSessionContract simply exists as a convenience for us to make sure Session and StatelessSession implement some of the same signatures. Now, if you are talking about the *Implementor forms those are the same as any of

Re: [hibernate-dev] Master

2016-04-15 Thread Sanne Grinovero
Do you have a practical need for SharedSessionContract and SharedSessionContractImplementor to exist within the internal contracts of ORM? As a general rule, I don't mind having implementations which implement multiple interfaces. Assuming you need these as a convenience for internal helpers,

Re: [hibernate-dev] Master

2016-04-15 Thread andrea boriero
+1 SharedSessionContractImplementor <- (Session Implementor & StatelessSessionImplementor) On 15 April 2016 at 14:30, Steve Ebersole wrote: > So here is what I ended up doing, with one questionable decision which I'll > highlight below. > > First, the existing situation...

Re: [hibernate-dev] Master

2016-04-15 Thread Steve Ebersole
So here is what I ended up doing, with one questionable decision which I'll highlight below. First, the existing situation... We have Session and StatelessSession which are largely independent contracts. There is a "shared" bit that is represented by an interface SharedSessionContract. There