4 ms·

shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Rust is not OOP language, so it's logical that it can't do this. Rust got ty

by Kilgort 12y ago

shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Rust is not OOP language, so it's logical that it can't do this. Rust got type system more like Haskell, and for me it's a big plus as I don't like C++ OOP that was taken from Simula and not even from SmallTalk. I don't like talking like this, but C++ OOP is complete trash(beat me for talking like this). Also you are saying that Rust is not alternative for C++ in some ways trying to find what Rust don't have that C++ have. Those languages are completely different conceptually, but they target the same level. Rust is good alternative for C++ even now, taking for consideration that it's not stable(1.0 version will be soon, but it's not there yet). There is no areas where Rust is no alternative for C++, because you can tackle any low-level problem with it, that you can tackle with C++. I don't want to say what language better, because it's not the best comparison. For now, all I can say that Rust is more sense full and more conceptually accurate, it's syntax is more concise and easier to understand than syntax of monstrous language like C++. For the first in the long time we can say that we got low-level language with ability to write code using high-level abstractions and it will be effective. We don't need to drop code understanding for low level optimizations, yet we have power to fully optimize bottlenecks. It's not silver bullet for sure, but guys did a big job here, showing that low level language can be more clear for human.

humanrebar 12y ago
> shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Not sure what you're trying to do there, but Rust can certainly alias one object with more than one trait reference. In this particular case, you're using two mutable references to the same object, which Rust doesn't allow. But if both were immutable references, there wouldn't be an issue, assuming the right declarations preceded your code.
- Matthias247 12y ago
  It was my example, so I try to explain it a little more: There are quite a lot of cases where you would like to have things like this, but the example that's probably most straightfoward to understand is GUI systems: E.g. you have a generic `Widget`, the `IWidget`. Then you have some base-class `Container` which contains multiple other widgets (`list<IWidget>`). This might contain a reference to a `TextBox` (which is an implementation of `IWidget`) and another widget (or controller or whatever) might contain also a reference to the same thing. Both might need to be mutable. And in exact that moment you have code like the described one. That's no borderline usecase, it's a thing that you in all popular HMI frameworks (and in C, C++, C#, Java, ...). Maybe you can solve the issues in a completly different fashion, with resorting to only immutable objects (like some approaches for ClojureScript). But these are then no longer zero-cost abstractions versus current technology and they are not that easy to pick up for most mainstream programmers (which expect C++ alternative and not a Haskell alternative). Besides that people are already asking for bindings to things like QT - and that will require similar constructs.
  - humanrebar 12y ago
    I'm not aware of any production quality UI toolkits in Rust, but using traits and reference counting, Rust certainly supports this use case. In fact, it supports it more flexibly since different widgets don't have to share the same methods and data at all... well, unless you want them to. And you can have your widgets implement more than one trait without having to combine them all into one giant class definition.
    - Matthias247 12y ago
      As soon as it supports storing trait objects in smart pointers and casting them. That's afaik still not the case.
      - humanrebar 12y ago
        You can as long as they are immutable objects. Again, you can't alias mutable references, even if they are of the exact same type. Maybe you should read this: http://doc.rust-lang.org/guide.html#traits http://doc.rust-lang.org/guide.html#traits
        steveklabnik 12y ago
        I believe your parent is referring to storing trait objects in something like Arc<T>, which is not supported: currently, Arc<T> requires T to be sized.
        Matthias247 12y ago
        Similar, but not exactly: As I said, the objective is to have access to one object (in it's native form or in an interface (supertype) form from different locations. For that you can can use Rc. To be able to mutate it you can add RefMut and end up with Rc<RefMut<T>>, e.g. Rc<RefMut<IWidget>>. And now how do I get an Rc<RefMut<TextBox>> or any other type like &mut TextBox back from that?

by Kilgort 12y ago

humanrebar 12y ago

> shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Not sure what you're trying to do there, but Rust can certainly alias one object with more than one trait reference. In this particular case, you're using two mutable references to the same object, which Rust doesn't allow. But if both were immutable references, there wouldn't be an issue, assuming the right declarations preceded your code.

Matthias247 12y ago
It was my example, so I try to explain it a little more: There are quite a lot of cases where you would like to have things like this, but the example that's probably most straightfoward to understand is GUI systems: E.g. you have a generic `Widget`, the `IWidget`. Then you have some base-class `Container` which contains multiple other widgets (`list<IWidget>`). This might contain a reference to a `TextBox` (which is an implementation of `IWidget`) and another widget (or controller or whatever) might contain also a reference to the same thing. Both might need to be mutable. And in exact that moment you have code like the described one. That's no borderline usecase, it's a thing that you in all popular HMI frameworks (and in C, C++, C#, Java, ...). Maybe you can solve the issues in a completly different fashion, with resorting to only immutable objects (like some approaches for ClojureScript). But these are then no longer zero-cost abstractions versus current technology and they are not that easy to pick up for most mainstream programmers (which expect C++ alternative and not a Haskell alternative). Besides that people are already asking for bindings to things like QT - and that will require similar constructs.
- humanrebar 12y ago
  I'm not aware of any production quality UI toolkits in Rust, but using traits and reference counting, Rust certainly supports this use case. In fact, it supports it more flexibly since different widgets don't have to share the same methods and data at all... well, unless you want them to. And you can have your widgets implement more than one trait without having to combine them all into one giant class definition.
  - Matthias247 12y ago
    As soon as it supports storing trait objects in smart pointers and casting them. That's afaik still not the case.
    - humanrebar 12y ago
      You can as long as they are immutable objects. Again, you can't alias mutable references, even if they are of the exact same type. Maybe you should read this: http://doc.rust-lang.org/guide.html#traits http://doc.rust-lang.org/guide.html#traits
      - steveklabnik 12y ago
        I believe your parent is referring to storing trait objects in something like Arc<T>, which is not supported: currently, Arc<T> requires T to be sized.
        Matthias247 12y ago
        Similar, but not exactly: As I said, the objective is to have access to one object (in it's native form or in an interface (supertype) form from different locations. For that you can can use Rc. To be able to mutate it you can add RefMut and end up with Rc<RefMut<T>>, e.g. Rc<RefMut<IWidget>>. And now how do I get an Rc<RefMut<TextBox>> or any other type like &mut TextBox back from that?