Task should be an interface, not an anonymous function about gocelery HOT 6 CLOSED

Thank you for the issue.
I think its great idea but it might also add burden of extra code to users.
You can achieve same effect by registering member functions instead.
Take a look at below example.

type MyObject struct {
    MyInt int
}

func (mo *MyObject) add(a int, b int) int {
    return a + b + mo.MyInt
}

func main() {
    mo := &MyObject{999}
    celeryBroker := gocelery.NewRedisCeleryBroker("localhost:6379", "")
    celeryBackend := gocelery.NewRedisCeleryBackend("localhost:6379", "")
    celeryClient, _ := gocelery.NewCeleryClient(celeryBroker, celeryBackend, 2)
    celeryClient.Register("worker.add", mo.add)
    go celeryClient.StartWorker()
    time.Sleep(30 * time.Second)
    celeryClient.StopWorker()
}

from gocelery.

Even if you CAN pass a bound method to Register (does it need to have a pointer receiver to do this?), in idiomatic Go this kind of thing is usually accomplished using an interface. Most use cases for Celery I've experienced in production environments involve a lot of moving pieces and are rarely very simple functions like this.

If you don't want to change the API and still have this as a feature, a runtime type assertion could determine if the second parameter of Register implements the Task interface and can handle it differently.

from gocelery.

Above code works and pointer to interface is not correct type to hold pointer to struct.

I assume that you want to model after Celery task class in Python implementation.

Certainly your approach would mirror that.
You are always welcome to create pull request =)

from gocelery.

I think you're misunderstanding what I'm trying to say. The article you linked is about pointers to interfaces. I'm referring to the method you're adding to register (add) having a pointer receiver.

Regardless, I think a PR will clear up confusion. The "Celery task class" is the correct approach to take in Go.

from gocelery.

Oh I see what you mean.
It doesn't necessarily have to be pointer receiver. (I have tested)
As far as I understand, the difference is whether you want to pass object by reference or by value to the method.

Also one problem I can see is that gocelery only supports args at the moment (not kwargs).
I think it'd be difficult to map args in your model using json.

But I do agree that its more aligned with standard go practice to use interface.
Perhaps, args can be supported by anonymous function and kwargs can be supported by your model.

from gocelery.

Using interface would provide performance gain over using reflection.
Only arguments passed through kwargs dictionary is supported using CeleryTask interface.

merged at a14372d

from gocelery.