On Thu, 19 Dec 2002, Costin Manolache wrote: > If this means another round of "where should this class be located" and > dependency nightmares: I'm -1 ( it is a majority vote and probably that > won't change the result, but I want to express my frustration somehow ).
This is meant as a resolution to round of "where should this class be located" discussions, and seems or at least seemed to represent an informal consesnsus on the issue (cf <http://archives.apache.org/eyebrowse/SearchList?[EMAIL PROTECTED]&searchText=functor+-cvs&defaultField=body>). > It seems one of the reasons for this proposal is that both collections > and lang have something like that and can't agree on a dependency. > A better solution would be to have a majority vote ( or flip > a coin ) to decide which of the 2 should have functor, and live with the > result. Those aren't my reasons. For me, the primary reasons for this proposal are: (1) a functor-related component forms a cohesive, atomic unit that meets both the hard and soft criteria for a commons component--it has a clearly defined purpose and scope, it does one thing, and hopefully will do it well. The functor types are likely to be used, changed and released together, and to be mutually dependent. (The same statements are not true for either functor-in-lang or functor-in-collections.) (2) there is some demand for a functor-related component, as witnessed by the similar code in collections and lang (and it's easy to find instances of functor-related interfaces throughout commons and for that matter jakarta), and the sometimes lively debate on this issue. > Or just pick a neutral interface and have both implement the interface. Well yes, that's one approach. Arguably, that's this approach. But absent functor, where does that interface live? > Or even better - pick a design pattern ( a method name and signature ) I suspect there is a reason no one has developed the "design patterns framework", or for that matter, why design patterns are generally expressed as prose rather than code. > and use reflection to wrap any class that implement the pattern. A reflection-based implementation (for instance, something like MethodPredicate(Object,Method)) seems appropriate in some circumstances (indeed I've had something like that in mind for a little while), but again, absent functor, where should that functionality live? For an extended analysis of this situtation, see my next post. - R. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
