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
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
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,
+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...
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