ray: Resolving inconsistencies in the API.

Right now, there are several inconsistencies in the API. Some of the following may be fine.

  1. We change the way that we call remote functions (versus regular functions), that is f.remote() versus f(). But we do not change the way we instantiate actors (versus regular classes), both are just Class().

  2. We change the way we call remote functions (versus regular functions), that is f.remote() versus f(), but we do not change the way we call actor methods (versus regular class methods). Both are c.method().

  3. The word remote is an adjective, but actor is a noun.

There are a handful of options.

A. (addresses 1 and 3) Replace @ray.remote and @ray.actor with @ray.task and @ray.actor respectively. Call remote functions with f.remote(). Create actors with Class.remote().

B. (addresses 1 and 3) Replace both @ray.remote and @ray.actor with @ray.remote. Call remote functions with f.remote(). Create actors with Class.remote().

C. (addresses 1 and 3) Replace both @ray.remote and @ray.actor with @ray.remote. Call remote functions with f.task(). Create actors with Class.actor().

Note that none of these address problem (2). The issue with (2) is that calling c.method.remote() or something like that is kind of verbose. There are probably good options that I’m not thinking of right now.

cc @jacobandreas @pcmoritz @istoica

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

I love the move to function and class. Getting rid of actor is actually a good thing, IMHO. The notion of a class was actually invented to encapsulate state – it was the original OO motivation for it, so it’s very fitting to call it a class semantically.

I also strongly support the unification of the calling interface for functions and methods with the remote suffix. The only tweak I would consider is getting rid of the remote suffix when instantiating the Ray Class. That way, all calls to remote can participate in the hybrid dataflow, return an object ID, and are easily identifiable in the code as places that trigger task submission to Ray. I think it’s important that we have this futures composition marker well defined.