facets

[Kevin Bealer]

In article <du4njo$19sf$1 at digitaldaemon.com>, Sean Kelly says...
>
>Kevin Bealer wrote:
>> I like the on_scope_exit() and friends, by the way.
>> 
>> But it got me thinking about an idea I had.  It's a bit like aspect
>> oriented programming, but that is usually done with classes.  This is
>> a function based one.  The name I'm thinking of for this is "facet
>> programming", sort of suggesting "function based aspects".
>> 
>> The idea is to have semi-independent functions that can be "zipped"
>> together at specified points to combine different implementations of
>> sub-functionalities, or to add and remove those elements.
>
>I really like the potential of AOP in general, however this seems more 
>of a proposal to add language support for concurrent programming.  And 
>while I think that idea has merit as well, I'm not sure I want to 
>confuse the two.  In my experience, AOP is a way to inject functionality 
>into arbitrary code blocks without the need to do so manually.  This can 
>be invaluable during maintenance if a need arises that the original code 
>wasn't designed for, as it doesn't require the original code to have 
>made any attempt at allowing for such code injection.  But parallelism 
>is a separate issue as far as I'm concerned.
>
>
>Sean

I agree - AOP is good and parallelism is not as interesting.

The goal of my proposal is not to parallelize code, though - in fact I don't
really see how it can help in that regard.

I think there are significant benefits to be had from splitting functions into
smaller functions - each smaller function dealing with a specific aspect of the
task at hand. 

However, I'm not as concerned about AOP as a way of maintaining code that did
not intend to have a given feature - I want to design code to be 'horizontally
composable' from the start.  If I know that a transaction has a script like this
(to make up an example):

a. Set up GUI and connect to local DB and remote server.
b. Get request from user.
c. Find local data in db.
d. Send it to a remote service.
e. Poll until done.
f. Read and parse the output.
g. Display the output on GUI, and maybe in a local file.

This design will result in a large, complex function.  You can break that up
into sub functions, which is a good idea, but... we would like all the DB stuff
to be grouped, and all the GUI stuff to be grouped, and all the user interaction
to be grouped.  This grouping is hard to do if the actions are interspersed in
this way.

What you end up with is a dozen little functions -- each one potentially
interacts with database, gui, and remote server.  The code that deals with the
GUI, for instance, is probably spread over all these functions.

The facet idea, allows this script to be an explicit part of the design.  It
allows the GUI code to be grouped in one location.  Likewise for the DB code,
remote connection (and synchronization, and ..).  Each can be written as
seperate function-like elements that are later joined.

If you change the DB locking, you only need to touch the DB facet.  What object
oriented does for data is seperate things that are unconnected, and group things
that are related.

I want to do this for code - split things up that are unrelated, and group
things that are related.  Just as the scope_exit() macro groups construction and
cleanup of a resource.

Right now, proper design can make this design cleaner, but facets (or maybe a
similar, better mechanism) could make it MUCH cleaner.

Kevin