[aosd-discuss] Hyper/J vs Apect-J

[leeca at pnambic.com]

Laurent -

> From: Laurent Martelli
> Subject: Re: [aosd-discuss] Hyper/J vs Apect-J
>
>   leeca> Tzilla - In my work, I've been able to simplify component
>   leeca> interaction into 4 variations:
>
>   leeca> - fusion (or joining) of behaviors
>   leeca> - dispatch (or single selection) among behaviors
>   leeca> - nesting
>   leeca> - sequencing
>
> Could you elaborate on this please? I have difficulties imagining real
> world examples corresponding to these variations.

One way to understand these interactions to to consider class inheritance as
a form of evolutionary enhancement.  In this framework, it's easy to map
common OO interactions to the 4 variations above and to see the limitations
of conventional OO class derivation.  Consider a simple C++ style class:

class Blix {
	Blix () { ... }				// A constructor
	~Blix () { ... }				// destroy() in Java
	virtual int bump () { ... }		// Runtime-type dispatch
	int fudge () { ... }			// Static type dispatch
	}

and a derived class:

class Blax : public Blix {
	Blax () { ... }				// A constructor
	~Blsx () { ... }				// destroy() in Java
	virtual int bump () { ... }		// Runtime-type dispatch
	int fudge () { ... }			// Static type dispatch
	}

If we view Blax as an evolutionary enhancement to Blix, the interactions
behaviors are fairly interesting:

- The Blax constructor is "fused" with the Blix constructor, and sequenced
to execute _after_ the Blix constructor.

- The Blax.bump() and Blax.fudge() member functions define alternative
actions for their interfaces.  For the virtual function bump(), the compiler
will generate dynamic dispatch code (e.g. virtual tables).  For the
non-virtual function fudge(), the compiler selects an alternative using
static type information.

- The Blax destructor is fused with the Blix destructor, and sequenced to
execute _before_ the Blix constructor.

A C++ compiler generates these interaction rules automatically.
Unfortunately, these rules are rigidly enforced within the compiler.  Even
simple variations are not allowed (or awkward).

- If you want automatically add a behavior to a interface, the interface
must be a constructor or a destructor.  Depending on this choice, the added
behavior will always come last (ctor) or first (dtor).  (Yes, it is easy to
have a derived method explicit call the parent implementation, but that is
not automatic.  And it is easy to get it wrong.)

- Runtime dispatch is only available for type-based selection.  If your
selection criteria depends on more complex state or user input, you must
write the dispatch mechanism yourself.

AspectJ and Hyper/J both provide enchanced support for developer specified
fusion sites and developer specified sequencing.  This is a great benefit
over traditional OO approaches to evolutionary development.  I can
(anonymously?) extend any composition site with _additional_ behaviors, even
if the site is not a ctor/dtor.  And I am not limited to a single, language
defined execution sequence.

AspectJ has some interesting "non-type-based" mechansims for selection
interactions (e.g. cflow), but I would like to see this generalized.  In
Hyper/J, it's possible to do general purpose dispatch compositions, but it
this takes custom integration support for each composition site.  Doug
Orleans has pointed out that mulitple dispatch is a good model for general
purpose enhancements with selection/dispatch interactions.  However, this
must be generalized to include value and other non-type-based dispatch.

I'm sure this raises additional questions, but I hope it explains my basic
notions of fusion and dispatch interactions.
---
http://www.pnambic.com/leeca
... The real cycle you're working on is a cycle called 'yourself'.