Authors CurseForge

I was writing yet another throttled onupdate, and i figured, I'd try to write something that was easier to reuse.

Maybe we could improve upon this so we have a reusable version of throttled onupdate for people to use.

Anyhow, here's the code (its dry code until I edit this post after testing)

local function throttle(func, interval)
    local THROTTLE_TIME = interval
    local throt = THROTTLE_TIME

    return function(self, elapsed, ...)
        throt = throt - elapsed
        if throt < 0 then
            throt = THROTTLE_TIME
            func(self, elapsed, ...)
        end
    end
end

here's how I used it:

local function sample(self, elapsed)
   -- My throttled OnUpdate handler code here
end

local frame = CreateFrame("Frame")
frame:SetScript("OnUpdate", throttle(sample, 0.1)  )

Enh, what the hell, I'm waiting on SWMBO to finish stonecore so we can get some lunch. I've got time.

Get a whiteboard or a scrap of paper. Drawing boxes and lines with arrows is a big help to visualization. Evaluate expressions the same way the engine does:

frame:SetScript("OnUpdate", throttle(sample, 0.1)  )

First thing to boil down is sample and 0.1. Okay, done, they're already as boiled-down as they can get. The first is a reference to a function, the second is just a number.

Next is throttle, which could be called something like make_throttle or throttle_factory instead. ("Wrapper" describes a slightly different behavior, but that's a different topic.) I'm going to rewrite syl's code a little bit for purposes of exploration:

local function throttle (reference_to_periodic_function, interval)
    -- Starting point.  The name in all caps hints that it's a constant value.
    local THROTTLE_TIME = interval
    -- Initial countdown.
    local throt = THROTTLE_TIME
    -- What we're handing back.
    local result

    result = function(self, elapsed, ...)   -- same as "function result (self, elapsed, ...)
        throt = throt - elapsed
        if throt < 0 then
            throt = THROTTLE_TIME
            reference_to_periodic_function(self, elapsed, ...)
        end
    end

    -- Hand back a function which periodically calls the function whose
    -- reference was passed in.
    return result
end

The body of result is exactly like every other throttled OnUpdate function we've seen copied around on these boards. That's because every other throttled function IS exactly the same, except for the part down in the conditional branch that "does the real work". So here, the "real work" is factored out into its own function, and a reference to that function is passed in to the factory. The factory creates a little function of its own which *calls* the real work, and gives the user that function.

The little result function has its own "THROTTLED_TIME" and "throt" variables. They continue to exist after the factory has returned, because result still refers to them, and result continues to exist.

So this now has boiled down to

frame:SetScript("OnUpdate", <reference to "result" function>  )

except that now each time Syl wants to make this kind of periodic throttle function, there's none of the copy-and-paste code for counting down and resetting the timer cluttering up the "real work".

So each frame refresh, the OnUpdate script is called, passing in a frame reference and the elapsed time. The call from the WoW client would be as if:

result (frame, some_elapsed_time, args...)

Inside, "throt" gets decremented by some_elapsed_time, and if the counter has run down, it gets reset and reference_to_periodic_function is called with the same arguments. That function reference is sample, originally passed into the factory function.

Quote from lilsparky

yeah, factory is better way to decribe it than a wrapper.

How about ThrottledOnUpdateFactory

Quote from lilsparky

i wouldn't put "OnUpdate" in there just because this could useful for other things you'd like to throttle (for example, BAG_UPDATE or other potentially fast-firing events).

As is, it can only work out of the box with OnUpdate, so I think "ThrottledOnUpdateFactory" is appropriate.

With fast-firing events, you should use something more complex, probably using some kind of bucket.

Quote from jerry

This is similar to python decorators: http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Decorators

I think this is an example of the Decorator design pattern.

Quote from Elsia

Factory is a bad word. Returning functions is natural in functional programming language. Lua is brilliant exactly because functions are first order types.

Factories are artifacts of object-oriented languages trying to cope with the gnarliness of rigidity of the OO data/method organizing principle in cases where you actually do not want quite so strong a rigidity. Luckily lua has a loose data structure that can be flexibly be associated with functions, so no need to factory a solution. Just return a function and make sure it has access to the data it needs.

It was just a suggestion. Didn't mean to touch a nerve.

IMHO, anything that communicates the purpose well and clearly, especially to users trying to learn, is a win. Language design wars take a distant second.

Quote from Elsia

Factory is a bad word. Returning functions is natural in functional programming language. Lua is brilliant exactly because functions are first order types.

Factories are artifacts of object-oriented languages trying to cope with the gnarliness of rigidity of the OO data/method organizing principle in cases where you actually do not want quite so strong a rigidity. Luckily lua has a loose data structure that can be flexibly be associated with functions, so no need to factory a solution. Just return a function and make sure it has access to the data it needs.

Actually OOP isn't a bad thing as your wording suggests. It's just a different programming paradigm. Both have different rules, advantages and drawbacks.

Ok, how about "TrottledOnUpdateGenerator"