Fix usage of RemoteRef

[yuyichao]

Ref JuliaLang/julia#13923

@amitmurthy

[tkelman]

is this a compat.jl candidate?

[yuyichao]

Possibly (Ref JuliaLang/julia#14458). Can both Future and RemoteChannel be changed to RemoteRef on 0.4?

[amitmurthy]

Not 100%

What will work by replacing Future/RemoteChannel with RemoteRef:

Future()
Future(pid::Integer)
RemoteChannel()
RemoteChannel(pid::Integer)

What will not:

RemoteChannel(f::Function)
RemoteChannel(f::Function, pid::Integer)

Also, since Future s are write-once, any code that relies on an exception on a second put! on a Future will fail. Practically, this may not be an issue.

[yuyichao]

But it seems that code that want to support 0.5 (without depwarns) but don't want to use the new features should work if Future and RemoteChannel are defined as RemoteRef?

[amitmurthy]

Code written for 0.5 but needs to work on 0.4 will have to consider previously mentioned issues.

Code written for 0.4 that needs to work on 0.5 will have to deal with the following:

• All remotecalls now return Future s instead of RemoteRef. So code collecting refs into an array defined as refs=RemoteRef[] will need to be changed to refs=Future[]. As with the comprehension syntax.
• take! on a Future throws an exception, while on a RemoteRef would just block/succeed.
• A second put! on a Future throws an exception, while on a RemoteRef would just block/succeed.

This is a breaking change and while some cases can be handled via Compat.jl, I don't think we can handle all cases.

[yuyichao]

I'm more thinking about having a Compat entry to avoid the version check due to renaming in simple cases like this. If this is not the case in general we can probably leave it as is.