[Tuningforkvp-development] Major ForkTalk Check-in also affects Stream / Event / Tuple / EventType hierarchies

[Joshua A. <jo...@us...>]

A somewhat working ForkTalk is checked in.  The GUI is still extremely
primitive and some aspects of the language are still incomplete but it is
now possible to do some stream derivations using ForkTalk.   Testing of new
functionality has been light.   I hope I've done enough regression testing
but the possibility of breakage remains.

This checkin involved some rippling changes that you might need to take
into account even if you don't care about ForkTalk.  I describe them in
this note.  The ForkTalk functionality is too extensive to cover in a
check-in note and I am overdue to check stuff in prior to another round of
changes.   I'll send some ForkTalk usage instructions separately
(eventually) or else talk to me.

1.  The class formerly known as EventType is now called TupleType and it
gains two new methods: hasTimestamp() which returns false, and getFactory()
which will be explained.   It loses its read() method.

2.  The new EventType extends TupleType.  It overrides hasTimestamp() to
return true and it overrides getFactory().  Thoughout the system, wherever
EventType was used to describe an ITuple specialization that isn't an
IEvent specialization, TupleType was subsituted for EventType.

3.  A new interface, TupleFactory, has the read() method that was removed
from EventType/TupleType and also has a newInstance() method.    The
getFactory() method that was added to TupleType and overridden in EventType
provides generic behavior, returning the best kind of factory for those
cases.   PersistedStreamData now gets the factory outside the loop and uses
the factory in the inner loop, which should improve performance for those
cases that don't specialize the EventType.

4.  Two new abstract classes, StaticEventType and StaticTupleType, extend
EventType and TupleType, respectively, and they implement TupleFactory.
Their getFactory() method returns 'this', and their read() and newInstance
() methods are abstract.  Every class that used to extend EventType now
extends one of these new classes.   Thus, all the old read() methods that
were placed in EventType specializations should continue to work.
However, each such specialization gains a newInstance method as well.

5.  There was an existing design pattern wherein data specialization
classes (like Sample) have a public static field named eventType containing
'the' single instance of the data class's associated EventType
specialization.   This convention is now required if the class is to be
usable from ForkTalk.   There are some funny corner cases where it was
impossible for the EventType specialization to have a single instance
because it needs constructor arguments having nothing to do with its
structure.  I have left some of these for now, meaning that there are some
tuple and event types that ForkTalk still can't construct.

6.  The addEvent method of Stream now takes IEvent instead of TypedEvent,
and the comment indicates that it should be overridden not only in base
streams (as before) but also in any stream that uses an IEvent as its
TimedData specialization (this now includes most streams).    In base
streams, the addEvent method just coerces its argument to TypedEvent and in
other streams that gained an addEvent, it just coerces its argument to the
appropriate type (e.g. Sample) and then calls the more specific adder.

7.  Stream has a new constructor, some new instance fields, and new run
loop method (called forkTalkRun).   Its getEventType method is no longer
abstract but will return an EventType stored by its new constructor.   The
new functionality only applies to ForkTalk derivations and is completely
bypassed by "normal" derivations.   This new construction pathway is
drilled upwards in selected places.   Specifically, EventStream and
SampleStream are no longer abstract and now support ForkTalk derivation.  I
will work on converting a larger set of Stream specializations after this
checkin.

Josh