I see no disadvantages from forcing the current session from overtaking the identity map changes. Its a natural feature addition that shouldn't cause any backwards compability issues.
Either someone had problems with too many objects of the same type and wrapped an identity session around a current PO version, or he never had an issue, which means he doesnt care about wheater an etnity is == or !==. Still if that is not an option i would go with your suggestions, otherwise ezcPersistentSessionInterface is also a good one. greetings, benny On Wednesday 22 April 2009 22:08:24 Frederik Holljen wrote: > Hmm... isn't that a bit obfuscated? How are people supposed to know > (without looking in the docs) what the purpose is for each of them? > > What exactly (short in your words) does the new one do? > > Frederik > > On 22/04/2009, Tobias Schlitt <t...@ez.no> wrote: > > Hi all, > > > > so far, the interface of ezcPersistentSession is only fixed by our BC > > standards. Now that ezcPersistentIdentitySession is introduced, we'll > > need to have an interface that both of these will implement, to be able > > to store them in ezcPersistentSessionInstance. Since > > ezcPersistentSession (the most logical choice for the interface name) is > > already taken, I'd suggest ezcPersistentObjectSession. > > > > Any comments? > > > > Regards, > > Toby > > -- > > Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards > > > > Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer > > > > t...@ez.no | eZ Systems AS | ez.no > > > > -- > > Components mailing list > > Components@lists.ez.no > > http://lists.ez.no/mailman/listinfo/components -- Benjamin Eberlei http://www.beberlei.de -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
