Jody Garnett a écrit :
> Okay I understand; I will break this up into two classes then...
> - BufferedAuthorityFactory which is abstract
> - DelegateAuthorityFactory which wraps up a single delegate
May I suggest to just completly ignore BufferedAuthorityFactory for now, and
see
at the end of th
Martin Desruisseaux wrote:
> It can be a DirectAuthorityFactory, but also a AuthorityFactoryAdapter
> which doesn't extends DirectAuthorityFactory...
Good point.
>> This contract is the same for both classes on the table; the code
>> will be the same at the end of the day; are you wanting to chan
Jody Garnett a écrit :
> I understand what you are saying; the part I miss is this - why is the
> separation into two classes useful?
Just a separation of concern (if we can do that without duplicating code), and
also because I believe that for a significant fraction of applications (e.g.
deskt
I have not done any work yet - I am getting the names in order first so
that we can have sane conversations over email.
I understand what you are saying; the part I miss is this - why is the
separation into two classes useful?
- createBackingStore - is used by all the createFoo(...) methods when
Jody Garnett a écrit :
> So the code is the same in both cases?
Yes but not repeated. It is repeated for now because I didn't wanted to break
the work you may be doing right now on ThreadedAuthorityFactory. But if
ThreadedAuthorityFactory extends BufferedAuthorityFactory, it would override
*onl
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> The problem is these are identical in implementation: even for case
>> of a single worker I am going to store it in an ObjectPool so I can
>> can remove all the Timer concerns about evicting the backingStore. I
>> need to show that am doing
Jody Garnett a écrit :
> The problem is these are identical in implementation: even for case of a
> single worker I am going to store it in an ObjectPool so I can can
> remove all the Timer concerns about evicting the backingStore. I need to
> show that am doing what we are paid for - making Geo
Martin Desruisseaux wrote:
> I means, we could apply on BufferedAuthorityFactory the same changes (using
> the
> object cache) that you applied on ThreadedAuthorityFactory. But by preserving
> BufferedAuthorityFactory in its current state (for now), we avoid that such
> change (if we decide to
Martin Desruisseaux wrote:
> In my "history fix" round, I restaured BufferedAuthorityFactory as it was
> before
> ThreadAuthorityFactory and as an independent class (not a subclass of
> ThreadedAuthorityFactory). This is because I feel that ThreadAuthorityFactory
> could be a subclass of Buffer
Martin Desruisseaux a écrit :
> In my "history fix" round, I restaured BufferedAuthorityFactory as it was
> before
> ThreadAuthorityFactory and as an independent class (not a subclass of
> ThreadedAuthorityFactory). This is because I feel that ThreadAuthorityFactory
> could be a subclass of Buf
10 matches
Mail list logo
