Chris Vine wrote: > > Not really if they are not implemented in the libraries, because then > > implementing conditions costs more than they save. If, however, conditions > > are implemented in the libraries, I'm sure it is worth it, saves coding for > > library users and makes error probability smaller. > > My comments assumed it was implemented in the library. The choice is between > three lines of code and, as I said and you agree, writing implementation > classes for each condition derived from condition_impl.
Three lines of code are repeated many times in each program using Glibmm. Besides, there is another reason: encapsulation gives smaller error probability. > > > Your approach is also rather inflexible - it can only synthesise from two > > > states. > > > > Yes, conditions cannot solve all problems. If you need some advanced > > checking, you should use traditional scheme, which doesn't go away. > > However, I'm sure that 75% of appropriate tasks are solvable with > > `standard' conditions. > > With a certain sense of deja vu, this would be relevant to gtkmm rather than > the libsigc++ library (yes, I know you want the substructure in libsigc++, > but I am talking about the condition implementation classes here, which is > what is relevant to any "standard" conditions you propose). Furthermore, in > my opinion (I accept not in yours) I doubt that there are sufficient > synthesised conditions not already in gtkmm which are suitable as a standard. I mentioned that conditions are simply convenient wrappers around signals, they give nothing new. Alas, I haven't heard from sigc++ maintainer so far :( Paul _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list
