The only methods that would have to be added to Context would be
getChainedContext() and setChainedContext(). AbstractContext could
still have loop detection but other implementations wouldn't need to.
If the interface supported getting and setting the next context I could
still do full loop detection in AbstractContext, but iteratively as
opposed to recursively.
--
Patrick
Geir Magnusson Jr. wrote:
> "Patrick E. Whitesell" wrote:
>
>> Well, how averse are you to adding to the Context interface?
>
>
> I think it depends. Making every context impl support this kind of
> advanced chaining isn't something that I think I would support w/o some
> convincing.
>
> Will respond to other post with alternatives discussion.
>
> geir
>
>
>> Geir Magnusson Jr. wrote:
>>
>>
>>> "Patrick E. Whitesell" wrote:
>>>
>>>
>>>> Hey fellas,
>>>>
>>>> I did some stuff to enchance the Context chaining. This is my first
>>>> submission, so let me know if I'm way out of line...
>>>>
>>>> There are some ugly bits in here due to the fact that the innerContext
>>>> is defined as a Context, not an AbstractContext. Does anyone object to
>>>> making the innerContext an AbstractContext? If not, I can take the
>>>> exceptions out of this code...
>>>
>>>
>>>
>>> And yes, w/o thinking much about it, my first reaction is that we want
>>> to keep it general as a Context, rather than the AbstractContext. This
>>> should keep things more flexible for chaining arbitrary contexts. At
>>> least that's the idea...
>>>
>>> geir
