Hi Johan:

David, who wrote the message below, 
took COM3360 last fall.

Please can you respond to the question on how TAO
compares to David's approach.
David appears to prefer a TAO approach over compile-time weaving.

Implementation files are in:

/proj/adaptive/www/evaluation/wagstaff

-- Karl

---------------------
Hi Karl,

I never took well to the abstractness of Demeter (not surprisingly, I've
given up trying to learn JavaCC, too), but I became hooked on Adaptive
Programming in Pure Java.  To the extent that I did use Demeter Method,
I couldn't convince co-workers to try it--even when I gave them Java
code produced by DemJava.

My portion of the final project explored, in part, Pure Java Adaptive
Programming (unfortunately, I sidetracked into fascinating issues of
cloned and threaded visitors.)  After your class, when I put the
principles into real projects, the code evolved into what I think is a
better style of Adaptive Java Code.  It's more readable and maintainable
because it's less tangled.  You said, "The art of computer science is
later and later binding."  DemJava uses a weaver to weave the aspects into
Java Code.  My style delays the weaving until runtime.

I want to write a paper describing my implementation because (1) I,
personally, love and use this approach.  I know it works.   (2) My
co-workers use it, too.  (3) I believe this design pattern will go
mainstream.  I need your advice because (1) You deserve credit.  I
didn't invent Adaptive Programming.  I just invented a clever Java
implementation.  (2) I want your feedback.  You've worked on this
technique for years.  (3) DemJava could be changed to delay the
weaving.  (4) You can steer me toward other sources.  You had a paper on
a Pure Java implementation.  I want to read it for
comparison/inspiration.  (5) Your understanding of DemJava will make a
better contrast.  My implementation is NOT a complete replacement.  The
DemJava abstraction is simply too powerful to be replaced.  I believe
the Pure Java approach is just a great simplification that works in most
cases.

My code is not well documented.  If I wait to do so, then I probably
wouldn't have written to you for months to come.  I've already delayed
months.  I finished this work in April.  As such, let me explain the
break throughs:

(1) Traversal object
(A) A traversal object does the weaving at runtime.  It takes an object
to be traversed, a strategy for the traversal, and a visitor.  The
traverse() method loops: (a) hands the object to the strategy which
returns the next subobject. (b) hands the subobject to the visitor. (c)
if the subobject can be traversed itself, recurse into it.
(B) Before and after traversing, it hands the traversal object itself to
the visitor.

(2) Strategy object
(A)Strategy classes are more tightly coupled with their targets than I'd
like; however, if the target object already uses a well-known
containment (I've included strategies for enumeration and iterator
trees) then strategies decoupled from their targets.  In other words,
unlike Demeter which is always structure-shy, this approach is sometimes
structure-shy.
(B)I invented my own interface instead of using a well-known one such as
enumeration or iteration because I wanted the traversal to be
intentional, not automatic.  Suppose my target object implements
enumeration, but that's not the order I want.  This way I can write my
own.  If I change my mind and want enumeration order, then I just plug
in the enumeration stategy.

(3) Vistor object
(A) The vistors can have before(Traversal host) and after(Traversal
host) methods. See 1B above.  I prefer these instead of
constructor/destructors(finalize()) because Java only does destruction
during garbage collection.
(B) The abstract Visitor object uses reflection to avoid changing its
code.  before(Visitor v, Object host) invokes v.before([correct class]
host) if it exists.  If it doesn't exist, just return.

(4) Filtering
Filtering can be done in the object itself, the strategy, or the
visitor.  I think DemJava can selectively prune out sections of the
graph easier.

(5) Sample Application--SBack.java
(A)I'm responsible for some backup scripts.  The script is just too
labor intensive and syntactically sensitive to do by hand.  To make
matter worse, there are changes daily to the list of files.  I create
two scripts by traversing a file/directory structure.
(B) I find 90% of my traversing is file systems.  As such I made a Dir
class because it made more sense to me than Java's file/dir composite
class.  At first most people do not like the change.  After a while you
realize how much easier the visitors become when directories are
distinct from files.
(C) You may ignore the standard WARNING header on the files.  There's no
company secrets inside.


Whew!  I'm sorry for the BOE (Back Of Envelope) discussion.  What do you
think?  Is this worth pursuing publication?

~David Wagstaff