IMHO stop the stringification (with some warning) and remove it from the pod as well. (and add it to the Migration document as well).
Gabor On Sun, Dec 14, 2014 at 2:27 PM, Sawyer X <[email protected]> wrote: > > You're right. I removed the stringification when redoing the API. I didn't > return it and the docs still retain that message. > > I'm still not sure whether it should stringify. That's always a source of > trouble. > > We could stringify with a deprecation or just keep it. > What is your opinion? > (other than that the docs should be up-to-date :) > > > On Sun, Dec 14, 2014 at 11:46 AM, Gabor Szabo <[email protected]> wrote: > >> Actually, I just noticed the documentation of both modules (Dancer:: and >> Dancer2::) have this in their pod: >> >> "For convenience the object will automagically return the RFC 2307 >> representation when no method is called on it." >> >> Which means it should still stringify to the rfc2307 value. >> >> Gabor >> >> >> On Sun, Dec 14, 2014 at 11:26 AM, Gabor Szabo <[email protected]> wrote: >>> >>> Finally I got to the point where I was actually testing the part where >>> Dancer2::Plugin::Passphrase is used and I think >>> I there is a change from the API of Dancer::Plugin::Passphrase >>> >>> It seems that the 'generate' method of the new module return a >>> Dancer2::Plugin::Passphrase::Hashed object >>> and does not stringify to the rfc2307 value as happened in the case of >>> the Dancer1 version. >>> >>> Looking at the documentation I see both say that I should store the >>> ->rfc2307 value, but because of the stringification I have missed >>> that earlier. >>> >>> If you decided to not include the stringification, then maybe this >>> should be emphasized in the docs as well. >>> >>> Gabor >>> >> >> >>
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
