1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
Similar structure to what is in 'src', but turned up-side-down. This
uses a 'listener' model, rather than iterators, to get data. It has
it's own problems... but gave me an opportunity to do some performance
checking and convince me that it doesn't really matter... This one is,
maybe, 3-5% faster. Not enough for even me to worry about.
1. This is NOT a full publish/subscribe model. It was important to
me that a 'listener' be able to communicate that it didn't need anymore:
halt processing (this is the alternative to defered processing that I was
using via iterators). This type of logic doesn't come cheap if you allow
multiple subscribers... so it's limited to just one (though that could be
a hook if anyone WANTs to allow multiple subscribes).
2. The code is much cleaner and easier to write...
4. It's MUCH easier to build up 'chains', simply connect each Discoverer
to the next (each is implemented as a 'listener').
3. Depending upon your point of view, it's not as convenient to 'get'
the data (data is 'pushed' to you via a listener, rather than 'pulled'
by you from an iterator). There are utility 'listeners' in
'o.a.c.d.listeners' for gathering all data, or just getting the first
(this means the 'first' non-null result from the last in the chain,
which is much nicer than monitoring the whole 'machine' as was done
when using Enumerations).
I think it's pretty cool... so I dumping it into a separate sandbox if
anyone wants to look at it.
We can figure out later which is the better direction.
|
