From e8c2c4f94a32d337217b835ca85c1c9894ae802f Mon Sep 17 00:00:00 2001 From: bbrtj Date: Fri, 5 Jul 2024 20:46:58 +0200 Subject: [PATCH] Clarify deprecation note on new_anon --- Changes | 3 +++ lib/Kelp.pm | 10 +++++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/Changes b/Changes index 5d1a031..ab626b7 100644 --- a/Changes +++ b/Changes @@ -9,6 +9,9 @@ Revision history for Kelp [Changes] - Fixed incorrect before_finalize class if last handler to execute did not belong to a controller + [Deprecations] + - Clarify that new_anon will not be removed, but rather use different implementation method in the future + [New Documentation] - Kelp::Context package is now documented - Kelp::Manual::Controllers has a new section: 'Use different method than reblessing' diff --git a/lib/Kelp.pm b/lib/Kelp.pm index b6698ab..14c72b6 100644 --- a/lib/Kelp.pm +++ b/lib/Kelp.pm @@ -688,9 +688,13 @@ A standard constructor. B be called multiple times: see L. my $kelp1 = KelpApp->new_anon(config => 'conf1'); my $kelp2 = KelpApp->new_anon(config => 'conf2'); -B. This only solves the problem in non-controller scenario and will -completely break with reblessing. It's usually better to treat every Kelp app -more or less like a singleton. +B. This only solves the problem in a basic scenario and has a +critical bug when it comes to subclassing and reblessing the app. The +C constructor itself will not be removed, but its internals will be +modified to use a more robust implementation method. It is not guaranteed to +work exactly the same for your use case with the new method. It's usually +better to treat every Kelp app like a singleton since that's how it was +designed. A constructor that can be called repeatedly. Cannot be mixed with L.