Re: Event Dispatcher
On Wednesday, 16 March 2016 at 15:14:57 UTC, Kagamin wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins. How about something like MEF? I didn't know about MEF before, I've just read an article about it, so correct me if I'm wrong. I think that MEF and such event dispatcher aren't comparable. Event dispatching is one of the principles how to extend the application. MEF as Wikipeda states "aims to solve the runtime extensibility problem". The important word is "runtime". So it is a higher level, it is about binding different parts of application at runtime. (As I understand it). Now Symfony, I'm inspired by, has a thing called Bundles. Bundles are just application plugins. And event dispatching can be used inside this bundles aswell. And it is the level where something like MEF would be really great. I think it should be really done, because it would make it possible for example to write closed source plugins for open source applications (it is very common in ecommerce, for example online shops, even for PHP, where you can decode your plugins with something like ioncube). Another area, where it could be used, is routing (already because plugins should be able to add routes to the application at runtime). So concepts like MEF are anyway something very useful for compiled applications/languages and I'll have to find a way to implement it on some stage. Thanks for mentioning it.
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins. How about something like MEF?
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:15:21 UTC, Adam D. Ruppe wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file: https://github.com/adamdruppe/arsd/blob/master/cgi.d some dox: http://dpldocs.info/experimental-docs/arsd.cgi.html It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy. Yes, I'm aware of your code, Adam. I'm using it for reference and looking if I don't how to implement something better. Thank you for this work!
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: In the last week I looked a lot into the vibe.d and I moved to its core for handling the requests instead of my own CGI-handling. I'm currently working on implementing SCGI based on vibe.d IO I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file: https://github.com/adamdruppe/arsd/blob/master/cgi.d some dox: http://dpldocs.info/experimental-docs/arsd.cgi.html It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy.
