Andreas Hartmann wrote:
IMO that is bad design. The framework has to present an unambigous API.
There should be no "most cases" approach - if you want a task done that's
not supported by the framework, you can't use the framework. In this case
the framework must be extensible. The question is if usecase overriding
is convenient enough or if we have to find a simpler mechanism.
It is fine with me to keep the Creator interface, as long as we remove
the parameter map. But, to be honest, I see a danger of misuse, because
people might try to pass information to the creator using adventurous
approaches like the session. If we can predict an interface to be
insufficient, we should ask ourselves if the interface should be introduced
(or, in this case, kept) at all.
failure to come up with a creator interface in the past clearly
indicates that it is not something that is easily generalizable, and
should therefore not be an interface.
+1 for removing it
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
