On 21/11/2010 11:08 PM, Graydon Hoare wrote:
To get static binding in rust, you have to use a static function call,
not an object-method call.
A final followup here. Brendan asked me in private email afterward if we
had considered any static binding forms for methods. We have considered
it, and I thought I'd point out how to do it here; it's not beautiful
but it would get us to a place where we could present much more C++-like
performance for a user-selected static subset of
things-that-look-like-method-calls.
The trick is to overload the 'self' keyword we're planning on
introducing to support self-typing inside objs. In the obj context it
indicates a recursive obj-type as well as the self-value for
self-dispatch; but it doesn't need to be limited to the obj context. If
you permit an additional use of 'self' *outside* the context of an obj
-- in static module functions -- you can do something cute:
mod _str {
fn append(self &mutable str s, &str other) -> str { ... }
}
then in any context where you've imported this symbol, visibility-wise,
we can tell the compiler to do a second-phase lookup on method calls to
see if they resolve via self-qualified functions in scope:
import _str.*;
log "hello".append(" there");
What would be going on here is not remotely like vtbl dispatch -- it's
just sugar for calling _str.append("hello", " there"), which you could
still call -- but it lets the user write in a "more OO style". You'd
want to run this lookup after primary field lookup, so you could mix
records-full-of-functions with static-bound methods like this. But it
could be done.
You could even go further and make a crate-level declaration between
datatypes and static method suites, such that a particular module is
automatically imported for static method binding -- solely for static
method binding -- anywhere the type is used. Something like this:
self mod str = std._str;
Advantages would be a blurring of the distinction between OO and non-OO
style; you'd get the OO syntax advantage in places you wanted it without
having to pay the obj-abstraction price (say, when you want to use a
particular concrete representation type in all cases, so it can be
interior-allocated, or just want faster dispatch).
Disadvantages would be the flip side of "blurring": you would have a
harder time knowing, when you look at a method-like call, how it is
dispatched. We already blur this to some extent by doing both module,
vtbl and record-field lookup using the same "." operator; this would
further muddy those waters.
Anyway, since it's completely compatible with existing plans either way,
I'm going to defer *implementing* this, but I thought I'd mention it in
passing. If anyone's really keen on it I'd accept patches to rustboot,
but until then I'm going to assume it can wait till after we're
bootstrapped.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
