Passing params / string name of job.

[cdrage]

Similarly to Resque, you only have to pass in the name of the function ("HelloWorldJob") and a list of params { foo:"bar" }, etc.

Is this possible with jobs? (or perhaps in future #14 implementation?)

Rough example (more pseudo-code than Golang lol):

job, err := Schedule("HelloWorldJob", 100, time.Now(), "{EmailAddress: "foo@example.com"}")
if err != nil {
    // Handle err
}

instead of

job, err := welcomeEmailJobs.Schedule(100, time.Now(), &User{EmailAddress: "foo@example.com"})
if err != nil {
    // Handle err
}

That means that within whatever program (whether it is an http server or whatnot), I don't have to define all jobs to say a:

var (
 sche *jobs.Type
)

everytime

[albrow]

@cdrage thank you for bringing this up :)

I am generally opposed to using strings to identify functions, objects, etc. They are prone to typos and are difficult for editors to analyze.

For example, if you accidentally typed Schedule("HelloWordJob", ...) the compiler would not be able to notice the mistake and it wouldn't show up until runtime, leading to issues that can be hard to debug. However, if you typed helloWordJob.Schedule and there was no variable named helloWordJob, the compiler would notice immediately (depending on your setup, your editor might notice before you even compile). In addition, your editor can probably autocomplete HelloWorldJob for you if it is a variable, but cannot autocomplete a string. I am a strong proponent of failing fast and relying on the compiler/editor to catch mistakes for you when possible.

Does that make sense? Please let me know if you have any additional thoughts.

[cdrage]

Ah, that makes sense.

It's a bit more idiomatic your way, less prone to errors. :+1:

I'm just going to face the fact that this isn't a replacement for Resque, but rather a different type of implementation, and I'm liking it more.