On Fri, Feb 14, 2014 at 2:26 PM, David Golden <xdg@xdg.me> wrote:
On Fri, Feb 14, 2014 at 1:41 PM, Warren Young <warren@etr-usa.com> wrote:
session()->{b} = 2;
I agree in principle with most everything you say, except for this above. You're violating encapsulation by modifying the internals of the object. As soon as you do that, you break the API contract and so, yes, mayhem results.
The fact that the object doesn't give you a useful API for direct modification is a flaw in the API, but going around it and expecting it to just "magically work" isn't really right.
I would have no objection to having get/set methods added to Dancer::Session::Abstract to allow you to modify keys. At the moment, modification would need to also trigger a flush. Or, the API needs to document that you need to flush as soon as you're done modifying.
Doesn't D1's Session interface already provide get/set via Dancer::Session::read/write: https://metacpan.org/source/YANICK/Dancer-1.3121/lib/Dancer/Session.pm#L53 And it seems to automatically do a flush after a write (unless is_lazy is set). -Naveed
I'd also be happy to see work done to defer flushing until after the request is handled (as D2 does). But someone has to do that work.
And that might have unintentional side effects, I'd say that the eager flushing when setting variables might have been an intentional compensation for the race condition inherent in session loading/saving.
David
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users