James Carman wrote:
>On Mon, May 11, 2009 at 7:35 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote:
>> James Carman wrote at Montag, 11. Mai 2009 13:17:
>>
>>> On Mon, May 11, 2009 at 3:01 AM, Jörg Schaible <joerg.schai...@gmx.de>
>>> wrote:
>>>> I think there is a basic agreement on this, but back now to functor. In
>>>> this case it means more or less to include complete functor into
>>>> collections just for sake of no dependency. So, why had been functor
>>>> created at all?
>>>
>>> Functors can be used outside the context of collections.
>>
>> This is right, but it does not answer the question.
>
>It answers that one question. :) But seriously, functors can be very
>useful programming tools. I use them a LOT in my code. I think
>having a generic functors package is a very good idea.
Which is exactly why Collections should not copy Functor. Either Functor
should be absorbed back into Collections, or Collections should have
Functor as a dependency, for otherwise users must maintain separate
functors for use with Collections and for other purposes. Users of both can
rely on the Collections functors for everything, but that de facto rolls
Functor into Collections for them. It also obligates them to adhere to that
approach, which has great potential for integration pain.
A key issue here is that parts of the Collections public API reference
classes / interfaces of Functor. Collections therefore must either own Functor
or depend on it. There is no reasonable way to split the two projects without
making one depend on the other. This is different from the case in some
Commons projects where classes are copied from another Commons
component for private, internal-only use. Note also that the same argument
applies to moving the functor-based collections to Functor: then Functor would
need to have Collections as a dependency.
John
