Re: Scope::Upper localize?

[Corion]

If you, as you claim, do have a real use case for Scope::Upper, I'm really interested in hearing about it.

The only "use case" I can come up with is getting a callback or releasing a resource once the calling scope is left. And I think that is much better achieved by cooperating with the calling scope and returning a Guard object (there are many implementations of that, on CPAN and outside). Especially as returning a guard object allows you to easily write a shim that can go between the scope that is relevant for leaving and the scope in which the callback is installed.

Maybe my imagination is just too limited, and I'd welcome if you can show where Scope::Upper is a solution.

[tobyink]

One reason I can think of would be if you need to localize variables $A, @B, %C in a lot of different places.

OK, you can repeat:

local($A, @B, %C);

all over the place... but it's good to not repeat yourself.

[Anonymous Monk]

Well, that particular usage case is code-smell

[Anonymous Monk]

Can you think of any usage for local?

If so, you've thought of a candidate for localize(), if the work involved in deriving the value assigned locally, requires multiple lines of boilerplate, and is used in more than one place.

If not, you will probably never want to look at the module again.

[Corion]

Certainly, but I imagine that this use case is better solved by Guard, with the benefit of having a finer grained control than just block scope.

I'm not sure what functionality outside of logging would make sense to add to local, so still my imagination is not inspired to come up with use cases where Scope::Upper feels like a solution.

[Anonymous Monk]

With Guard, you get to set up a call back when the scope is left to clean up whatever.

For my purposes, the only work to be done at scope exit, is for the previous value of the localized variable to be restored.

All the work is in deriving the value(s) of the variable(s) that need localizing. A common pattern of boilerplate code needed at the *top* of many different scopes and so a candidate for wrapping up in a sub.

But with local you cannot localize variables in your caller. With localize() you can. And the only required clean up is taken care of by the normal scope clean up.