AOP use case? (was Re: Proposed PEP: Treating Builtins as Constants in the Standard)

Daniel 'Dang' Griffith noemail at noemail4u.com
Wed Apr 21 07:31:15 EDT 2004


On Tue, 20 Apr 2004 10:33:36 -0400, Peter Hansen <peter at engcorp.com>
wrote:

>Daniel 'Dang' Griffith wrote:
>
>> On Mon, 19 Apr 2004 08:09:56 -0400, Peter Hansen <peter at engcorp.com>
>> wrote:
>> ...
>>>automated testing.  The most easily demonstrated one is where
>>>the builtin open/file calls are replaced with a simulated ("mock")
>>>file system which applies to *all* modules, not just a single
>>>module under test.  This functionality is critical to some people
>>>using Python with the Test-Driven Development approach to software.
>> 
>> Isn't this the use case for AOP you were looking for?
>>     --dang
>
>As you might imagine from my previous postings, I have no idea.
>I don't understand well enough what AOP really is to say,
>obviously (given my requests for compelling use cases so I can
>understand why I would even want to investigate it).
>
>Can you describe how AOP would solve this problem?  As I
>understand it so far, it has nothing to do with mock objects...

Probably not.
I'm not an "AOP person", but from what I understand, you could use
an AOP-enabled language to replace the real file system (or whatever)
objects with the mock objects.  This is roughly analagous to the
standard logging or auditing examples, wherein a program is doing what
it needs to do, meanwhile a cross-cutting aspect intercepts certain
operations and performing additional, or different, operations.
    --dang



More information about the Python-list mailing list