> My recent experience in using software construction as a means of
> exploring mathematical ideas has led me to rethink this position. Not
> that I would like to denounce modularity, but I think I need to redefine
> (for myself) its boundaries and limitations.
Was this rethink provoked because you weren't able to capture
some concern using the existing structures of your language?
If so, you might want to look at Aspect-Oriented Software Development
(AOSD). I summarized it in my MSc thesis as:
Some concerns are difficult to modularize cleanly with current
programming constructs: their influence is spread across the
system, and are said to \emph{crosscut} the system. Left in
non-modular forms, they lead to interdependencies between
modules, increasing the complexity of the code and requiring
yet more context to understand. Crosscutting concerns thus
inhibit reuse and increase the difficulty in determining the
effects or dependencies arising from changing a line of code.
AOSD provides new language constructs to support capturing these
crosscutting concerns. Most AOSD approaches have added new constructs
to existing languages (e.g. Aspect/J, HyperJ, and DemeterJ for
Java).
A good starting point is <www.aosd.net>, or the October 2001 issue
of CACM.
Brian.
--
Brian de Alwis | Graduate student | Software Practices Lab | UBC
"There is much pleasure to be gained in useless knowledge." - Bertrand Russell
----------------------------------------------------------------------
PPIG Discuss List ([EMAIL PROTECTED])
Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss
Announce admin: http://limitlessmail.net/mailman/listinfo/announce
PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
