Le 05/01/2015 11:46, Damien Sandras a écrit : >> (6) The fact that a base class isn't purely virtual is annoying... In >> the rest of the engine, a base class Ekiga::Foo is purely virtual for >> 100% of cases, and an Ekiga::FooImpl is provided with an implementation >> to cover 99% of use cases. Don't get in the way of the last percent! > > Yes, and I tend to disagree with that design which is too restrictive. I > have already discussed this design with many people > whose job is to program and design object-oriented code and they all > told me that it was really a weird design. However, it > just works, so that's ok for me now. > Uh... they never heard of separating the interface from the implementation? They never found it useful to quarantine code behind an interface so deps don't spread to the whole code base? They never used an interface to make polymorphism work?
I don't mean the idea of an action system is bad, it's just that I'm not convinced the current framework is sound. Notice that the current LiveObject framework with the MenuBuilder is already making it possible to export actions in a very dynamic way, so it has good things. It does lack centralization... I think the answer to my question (1) would help me understand more precisely what you want.
MenuBuilder was tied to the concept of menu. We are now architecting things behind Actions,
-- Damien SANDRAS Ekiga Project http://www.ekiga.org |