I'm not sure what you are getting at. Each instance declaration would
lead to a vtable, so a type can have multiple vtables for the
different typeclasses it belongs to, but this is linear, and not
something to be worried about at all. The vtable will live in the
crate that declares the instance. In Haskell, and this is probably
worth following, only the module that defines the type, or the module
that defines the typeclass, can declare an instance for a
type/typeclass combo. So if your crate can 'uses' (as in, links) a
given typeclass and type, it also see any instance declarations for
them.
Then, as in your example, when a function passes an int to a function
one of whose type parameters is restricted to type Number, that is the
point where the vtable for int/Number is looked up, and passed along.
As an optimization, you can make this vtable point to the int type, so
that you don't have to pass both the vtable and the type descriptor to
the polymorphic function.
Let me know if that doesn't make sense.
It does. By "looked up" you mean at compile time, right? If so it looks
like about as expensive as the object system that rust has right now. I
think the main difference then is in the uses.
The rust objects are more expensive than c++ ones, but they are not
likely to be used as often. For normal cases where we know all the
derived types, tags are the most natural solution and are very efficient
(specially in memory use!). Hopefully having more expensive but not as
commonly used objects pays off.
Type classes, in Haskell at least, are very common. If we can use them
as parsimoniously as we use objects, that should be OK. It then becomes
a question of preference. I can see programmers with functional
languages background preferring type classes and programmers with
dynamic languages background preferring the current object system.
Cheers,
Rafael
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
