> And, as I have said several times, I agree closures currently impose
> testability problems, but I think the answer there lies in providing
> better introspection tools to lessen those problems rather than
> advising people not to use closures specifically for those reasons.
OK, that's fair.
In order to support testing you'd need to be able to assign to closure
variables (for e.g. mocking) and read them (to test alterations to
global state). At that point it's a short leap to defining a decorator
that creates these nonlocals. Is there a compelling reason to use a
new syntax?
Devin
On Thu, Sep 29, 2011 at 1:26 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Sep 29, 2011 at 1:10 PM, Devin Jeanpierre
> <jeanpierreda at gmail.com> wrote:
>> It's absolutely pannoying that you have to prefix the globals like in
>> C, but deftime-assigned nonlocals are less convenient in other
>> respects too. e.g. try sharing a lock among multiple functions, or try
>> testing the usage of a lock, etc.
>> Sharing state amongst multiple functions is a solved problem - you use
> either a closure or a class instance to create a shared namespace,
> depending on which approach makes more sense for the problem at hand.
> However, both of those solutions feel very heavy when all you want to
> do is share state across multiple invocations of the *same* function.
> Hence the current discussion (and the numerous ones that have preceded
> it over the years). It's a tricky problem precisely because it doesn't
> take much to tip any given use case over the threshold of complexity
> to where it's a better idea to use a full-fledged closure or class.
>> And, as I have said several times, I agree closures currently impose
> testability problems, but I think the answer there lies in providing
> better introspection tools to lessen those problems rather than
> advising people not to use closures specifically for those reasons.
>> Regards,
> Nick.
>> --
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
>