Hello. I slowly master the growth, and decided to write a small application on it in order to better understand the principles of development on it. The problem I had literally immediately. Take, for example, such a spherical architecture in a vacuum, without characteristic complications:

trait Some { fn get_id(&self) -> int; } trait SomeFactory { fn create_some(&self) -> &Some } struct MyApp { factory: &SomeFactory } impl MyApp { fn new(f: &SomeFactory) -> MyApp { MyApp { factory: f } } } 

Without an IoC container, I can do something like this:

 fn bootstrap() -> MyApp { let factory = MyFactory::new(); MyService::new(&factory) } fn main() { let app = bootstrap(); app.run(); } 

But, naturally, I don’t want every time I change the parameter list in :: new, I’ve had to go into bootstrap and manually redo the application initialization. This is what I want to achieve:

 fn bootstrap() -> IoC { let IoC = IoC::new(); IoC.Register<SomeFactory, MyFactory>(); IoC.Register<SomeApp, MyApp>(); IoC } fn main() { let IoC = bootstrap(); let app = IoC.Resolve<SomeApp>(); app.run(); } 

In principle, whether the macro is important or not. Although, an implementation that will work at compile time rather than execution is even preferable.

Do you already have any practices, or maybe ideas on how to do this in a plant?

  • Let's start with the following: `fn bootstrap () -> MyApp {let factory = MyFactory :: new (); MyService :: new (& factory)} `can not be done, because it is not clear who will own the factory, you will have a lifetime error (MyService is going through a factory). - kstep
  • I think it's easier to look at aturon.imtqy.com/ownership/builders.html - ozkriff
  • @ozkriff, the builder is used when the object's parameters are determined by the context. If we talk about patterns, here a factory would be much better suited. In general, they are used in such cases if it is not possible to do something better. But a sane person will not push through factories through the entire application if there is no need to create an object that is not related to the context by the time of life. - Fynivx
  • I'm afraid the factory is so-so (at least according to the community) fits into the philosophy of Rust. Another link like this: github.com/jdavis/rust-design-patterns/blob/master/patterns/… - it will suddenly help. - ozkriff
  • @ozkriff, I'm afraid this is what I mentioned above. Yes, this may be an acceptable solution if the language does not allow for IoC implementation. But I am sure that it is possible in rasta) Firstly, there is a powerful system of compiler extensions, which is not included in releases yet, but if there is an opportunity to get access to AST implementation, it is very good for IoC already at the compilation stage. Secondly, there are std :: reflect and std :: repr, which seem to be able to receive metadata during execution, which may also be enough for implementing IoC. - Fynivx

0