commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [poll] [pool] picking descriptive class names
Date Sat, 25 Mar 2006 22:10:28 GMT
On 3/25/06, Sandy McArthur <sandymac@apache.org> wrote:
<snip/>
>
> The main behavior of the composite pools are configured via four
> type-safe enum types. I'll describe what each type controls and then
> suggest name variants. Let me know which one you think is the most
> self-evident and user friendly. Feel free to suggest new names.
>
> 1. "Specifies the how objects are borrowed and returned to the pool."
> a) BorrowType  b) BorrowStrategy  c) BorrowPolicy  d) BorrowBehavior
>
> 2. "Specifies the behavior of the pool when the pool is out of idle objects."
> a) ExhaustionPolicy  b) ExhaustionBehavior  c) ExhaustionType d)
> ExhaustionStrategy
>
> 3. "Specifies the behavior of when there is a limit on the number of
> concurrently borrowed objects."
> a) LimitStrategy  b) LimitPolicy  c) LimitBehavior  d) LimitType
>
> 4. "Specifies how active objects are tracked while they are borrowed
> from the pool."
> a) TrackingBehavior  b) TrackingType  c) TrackingStrategy  d) TrackingPolicy
>
> The enums above don't actually specify any implementation, they
> describe desired features of a pool. The actual implementation isn't
> broken down into four parts like that so try not to confuse how you
> would implement that feature with how you would request that feature.
>
<snap/>

Why isn't it broken down like that?

IMO, such enum types have limited use, unless we can guarantee
reasonable (ideally, full) closure. Often, it is not possible to
enumerate all the types / strategies / policies that may make sense
for the varying use cases that we only attempt to foresee. In many
cases, such as this one, my personal preference is to leave things
pluggable, rather than enumerable. We should instead, if you and
others agree, define the contracts between a "pool" and each of the
four "behaviors" that you list above. We can supply (n) out-of-the-box
implementations, but leave it open for a user to *easily* define a
(n+1)th should such a need arise (and I believe it will, sooner or
later).

As a concrete example, for [scxml], we define a SCXMLExecutor (the
state machine "engine") accompanied by a SCXMLSemantics interface [1].
The basic modus operandi for an engine is simple - when an event is
triggered, figure out which (if any) transition(s) to follow, and
transit to the new set of states executing any specified actions along
the way. However, there are numerous points of contention along the
way. Lets take dispute resolution for example -- when more than one
outbound transitions from a single state holds true. Which path do we
take? The default implementation available in the distro is puristic,
it will throw a ModelException. However, a user may want:

 * The transition defined closest to the document root to be followed
 * The transition defined farthest from the document root to be followed
 * The transition whose origin and target have the lowest common
ancestor to be followed
 * The transition whose origin and target have the highest common
ancestor to be followed

Even after one of above dispute resolution algorithms is applied, if
we end up with more than one candidate transitions, the user may want:

 * A ModelException to be thrown
 * The transition that appears first in document order to be followed
 * The transition that appears last in document order to be followed

To implement any of the above choices, the user may simply extend the
default SCXMLSemantics implementation, override the
filterTransitionsSet() method, and use the new semantics while
instantiating the SCXMLExecutor.

This approach means:

 * We don't have to forsee all dispute resolution algorithms, and
provide implementations
 * Users don't have to convince anyone that the algorithm they need is
useful, they can just implement it if they need it
 * We don't even have to contend that the default puristic behavior
that doesn't tolerate any non-determinism is the most common or the
most useful one, it is just one that is chosen as default (because I
personally believe it leads to better proof of correctness arguments).

Since we're talking about Pool 2.0 and beyond, perhaps a focus on
similar extensibility is justified, and maybe we should revisit the
enumeration approach, even before we get to names.

-Rahul

(long, possibly fragmented URL below)

[1] http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLSemantics.java?view=markup

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message