[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Cratera - a games-oriented Lua fork
- From: "Soni L." <fakedme@...>
- Date: Tue, 12 Sep 2017 08:11:06 -0300
On 2017-09-12 03:53 AM, steve donovan wrote:
On Sat, Sep 9, 2017 at 6:41 PM, Soni L. <email@example.com> wrote:
Rust has compile-time traits. But it does not, in fact, have runtime traits.
If you make a trait and impl that trait on someone else's struct, reflection
with that struct will not be able to see your trait, and thus won't be able
to make trait objects with it.
Since we're nailing down concepts here, I submit that such traits are
indeed dynamic. I have someone else's Foo struct, and implement Trait
for Foo. Box<Trait> is a trait object and has a vtable, so I can call
any Trait methods on it. But true, there's a key difference. If I
receive a trait object, I can't magically upcast that into the 'real'
underlying type Foo, since that information is thrown away (this gets
called 'type erasure'). Is this perhaps what you meant?
That's not dynamic: The whole process happens at compile time.
For example, dynamic typing means typing is done at runtime. Dynamic
traits means traits are done at runtime. This isn't the case with Rust.
In fact you can't even dynamically (using reflection/code that's not
aware of the traits/types) "DOWNcast" Foo into Trait! If you're not
aware of Trait (if you don't explicitly check for Trait), then the
compiler won't emit *any* code for Trait!
You also can't add and remove traits at *runtime*. Among other things.
In Cratera, even the TraitType (the one in obj:[TraitType].f()) doesn't
exist at compile-time. At compile-time, it's only a variable/name, and
it could come from anywhere, even a function argument!
(Perhaps you're thinking of a different meaning of "dynamic"? Because
"dynamic" in scripting languages always meant done entirely at runtime.)
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.