4 ms·
A class marked as "async" can still have regular methods, which are only available to the inside of the class (i.e. the process itself, not other processes send
by YorickPeterse 3y ago
A class marked as "async" can still have regular methods, which are only
available to the inside of the class (i.e. the process itself, not other
processes sending messages to it). So you can do something like this:
class async SomeProcess {
fn async some_message(...) {
...
some_helper_method
}
fn some_helper_method {
...
}
}
SomeProcess {}.some_message # This is fine
SomeProcess {}.some_message # This is a compile-time error
I toyed with the idea of _not_ allowing regular method and thus implicitly
making all of them async for an async class, but that might lead to a pattern of
async classes being "mirrored" by non-async "helper" classes just to reuse some
methods between the different messages of an async class, i.e. you end up with
this:
class async SomeProcess {
fn some_message(...) {
SomeProcessHelper {}.some_random_method
}
}
class SomeProcessHelper {
fn some_random_method {
...
}
}
- karmakaze 3y agoGlad to see you here. Thanks that all makes sense, as making the async class's method async by default would then needs another keyword to make one non-async. Is the mut marking also for consistency (and/or non-message methods)? Presumably each actor/object would only process one message at a time so could always have full access to all its data. One more question, is memory allocated globally or from arenas/slabs/etc?
- YorickPeterse 3y ago> Is the mut marking also for consistency (and/or non-message methods)? Presumably each actor/object would only process one message at a time so could always have full access to all its data. This is indeed correct: processes have exclusive access to their data and run a single message at a time. Still having to tag methods as mutable is to prevent you from accidentally mutating data, and to keep it consistent with regular methods.
- karmakaze 3y agoThis is all an amazing achievement, congrats on making it so far/long. I always felt that Rust wasn't a local maxima and there was something that could be added/removed. The only thing I'm not sold on is async (outside of actor use) vs futures where waiting explicitly blocks the waiter, but can be composed without waits. There seems to be some debate around Rust's choice of implementation.
- TylerE 3y agoI'm confused by SomeProcess {}.some_message # This is fine SomeProcess {}.some_message # This is a compile-time error Aren't those the same call? Or is it calling it twice that's the error? or did you mean the 2nd to call some_helper_method instead?
- oinargon 3y agoI'm guessing it's a typo. Should probably be SomeProcess {}.some_message # This is fine SomeProcess {}.some_helper_method # This is a compile-time error
- YorickPeterse 3y agoYou're right! Sadly I can't edit the comment any more to correct it :<